Problem bei MySQL-Datenbank mit VB2005

[Crusher47]

Hallo.

Ich habe ein kleines Problem. Ich möchte über VB2005 auf eine (derzeit noch lokale) MySQL Datanbank zugreifen. Die Verbindung zur Datenbank ist per MySQL-Connection realisiert worden (ist auch Vorraussetzung).

In einem DataGrid werden nun die vorhandenen Datenbanken mit zugehörigen Tabellen ordnungsgemäß angezeigt. Ich kann neue Elemente in die Datenbank einfügen, aber (und jetzt kommts) nicht verändern, aktualisieren oder löschen.

Ich bekomme die Fehlermeldung:
"Dynamische SQL-Generierung für den UpdateCommand/DeleteCommand wird nicht für einen SelectCommand unterstützt, der keine Schlüsselspalteninformationen zurückgibt."

Gut und schön, aber die Schlüsselspalteninfos kommen doch durch den Adapter als Wert zurück, oder denke ich da falsch?

Hier der Code:

    Private Conn As MySqlConnection
    Private Data As DataTable
    Private DaAd As New MySqlDataAdapter
    Private ComBuil As MySqlCommandBuilder

'Verbindung mit DB herstellen, Login, Aufrufen von DB, Tabelle + Inhalt in DataGrid

Private Sub tables_SelectedIndexChanged(ByVal sender As Object, ByVal e As EventArgs) Handles tables.SelectedIndexChanged
            Data = New DataTable
            DaAd = New MySqlDataAdapter("SELECT * FROM " + tables.SelectedItem.ToString(), Conn)
            ComBuil = New MySqlCommandBuilder(DaAd)

            DaAd.Fill(Data)
            ' Aufrufen der Tabellen und deren Inhalt im Datenbereich
            dataGrid.DataSource = Data
    End Sub

Private Sub updateBtn_Click(ByVal sender As Object, ByVal e As EventArgs) Handles updateBtn.Click
            Dim changes As DataTable = Data.GetChanges()
            DaAd.SelectCommand = New MySqlCommand("SELECT * FROM " + tables.SelectedItem.ToString(), Conn)
            ComBuil = New MySqlCommandBuilder(DaAd)
            Try
                DaAd.Update(changes)
                Data.AcceptChanges()
            Catch ex As Exception
                MsgBox("Fehler!", MsgBoxStyle.Information)
            End Try
    End Sub

Vielleicht kann mir ja einer sagen, wo mein Fehler liegt, ich blick hier echt nicht mehr durch. Vielen Dank für eure Hilfe.

[Andreas Kosch]

Hallo,

der MySqlCommandBuilder gehört (wie alle anderen CommandBuilder auch) in den "Giftschrank", denn dieser muss zur Laufzeit jedes Mal aufs Neue basierend auf der SELECT-Abfrage die INSERT-, UPDATE- und DELETE-Anweisungen dynamisch erzeugen. Dies ist nur dann erfolgreich, wenn er genug Informationen aus der Datenbank abrufen kann.

"Dynamische SQL-Generierung für den UpdateCommand/DeleteCommand wird nicht für einen SelectCommand unterstützt, der keine Schlüsselspalteninformationen zurückgibt."

Dieses Veto besagt, dass der MySqlCommandBuilder nicht erkennen kann, welche Spalte den Primärschlüssel (alias PRIMARY KEY) der Tabelle bildet. Ich würde daher zuerst prüfen, ob die Datenbanktabellen auch einen Primärschlüssel hat bzw. dieser einen geeigneten Datentypen nutzt.

...oder denke ich da falsch?

Die Frage ist nicht, welche Spalten die SELECT-Abfrage zurückliefert. Für den CommandBuilder ist entscheidend, dass der Primärschlüssel der Tabelle für das Programm als solcher maschinell erkennbar ist. Die kann zum einen über die vom Provider implementierte Methode GetSchemaTable erfolgen oder via aCmd.ExecuteReader(CommandBehavior.SchemaOnly | CommandBehavior.KeyInfo). Wenn die MySQL-Connection diese Informationen nicht liefert (weil intern nicht implementiert), steht der CommandBuilder nicht zur Verfügung.

[Crusher47]

Vielen Dank für deine Hilfe.

Ich hab übers Wochenende die Datenbank überprüft und es sieht tatsächlich so aus, als würde die MySQL-Verbindung die Information über die Schlüsselspalten in den Tabellen nicht zurückliefern.

Wäre es denn möglich, ohne diese Informationen auf die Datenbank schreibend/verändernd zuzugreifen, ohne das man jeden einzelnen MySQL-Befehl vordefinieren muß?

Ich hielt den CommandBuilder trotz seiner Einschränkungen (Befehlsgenerierung zur Laufzeit) eigentlich für ganz praktikabel bis zum Auftauchen dieses Problems...

[Bernhard Geyer]

Bei MySQL ist es immer eine Frage welche Version eingesetzt wird/wurde. Diverse Beta-Build und auch release-Builds liefern teilweise "müll" bei Abfrage der Systemtabellen um die nötigen Informationen zu bekommen.

[Crusher47]

Ich verwende MySQL 5.0.56, müsste so ziemlich die neueste Version sein.

[Bernhard Geyer]

Wirklich 5.0.56? Dann müßte es ja gegenüber der freien Version schon 5 neue Releases gegeben haben.