MySQL und MSSQL über ADO Problem beim EDIT

[Tomektor]

Hallo,

Ich soll über eine Standard ODBC Verbindung (über ADO) Daten aus einer Datenbank auslesen und während des Auslesens ausgewählte Datensätze editieren. Das Programm soll sowohl mit MySQL als auch MSSQL gleichermassen laufen (der Enduser bestimmt welche Datenbank er haben will und diese zwei (plus Oracle) müssen unter Garantie laufen!).

Vorgehensweise:
- Das Programm liest aus der Datenbank mehrere Datensätze über die ADOQuery aus ('select * from ' + Tabelle + ' WHERE Messaging LIKE "%' + Station+ '%"') aus.
- Die Abfrage wird gesendet
- über eine Schleife von ADOQuery.First über ADOQuery.Next bis zur Erfüllung von While not ADOQuery.EOF werden die richtigen nacheinander Datensätze in einem Fenster angezeigt.
- Hier muss der User die Nachricht entweder bestätigen (Update im Datensatz -> ein Feld wird gefüllt) oder abbrechen (es passiert nichts). In beiden Fällen wird das Fenster geschlossen und das nächste Fenster mit dem nächsten Datensatz angezeigt.
- Das Update des betreffenden Datensatzes erfolgt über ADOQuery.Edit -> ADOQuery.FieldByName(FieldName).AsString -> ADOQuery.Post.

Nun zum Problem:
Diese Anweisung klappt mit der MSSQL jedoch nicht mit MySQL!!

Der Fehler tritt bei der Ausführung von ADOQuery.Post:
EOLEException - Die zum aktualisieren angegebene Zeile wurde nicht gefunden

Den Fehler habe ich noch mal im Angang angefügt.

Woran liegt es denn?!
Logisch betrachtet: Es liegt an der MySQL Datenbank.
Soweit ich verstanden habe ist es MySQL nicht möglich verschachtelte Abfragen zu machen wie:
SELECT * FROM Tabelle WHERE note>(SELECT AVG(note) FROM Tabelle)

könnte es daran liegen? Ich hoffe nicht :?
Welche Lösung hättet Ihr?
Fragen über Fragen...

Hoffe auf eine Antwort.

Gruß

Tomektor

[Neuromancer]

Hallo Tomektor,

höchstwahrscheinlich liegt der Fehler eben an der Inline-Query.
Es dürfte IMHO ziemlich schwierig werden, eine gemeinsame Plattform für MySQL und MS SQL zu finden. Unterscheiden sich die beiden ja eigentlich im Namen nur um einen Buchstaben, dürften sie in der Funktionsweise da schon in mehreren Punkten differieren.

Ich hatte mit MySQL bis jetzt noch nicht das Vergnügen, aber was mir bis jetzt zu Ohren gekommen ist, war nicht gerade sehr überzeugend (außer, dass MySQL bis zu einem gewissen Punkt nix kostet). Ich denke, dass es wahrscheinlich von der generellen Strategie das Beste ist, das Projekt komplett so zu gestalten, als würdest du nur gegen MySQL arbeiten, denn eine Angleichung von MySQL auf MSSQL dürfte um einiges einfacher und Erfolg versprechender sein, als der umgekehrte Weg. (Ich behaupte mal großkotzig: Was MySQL kann, kann MSSQL schon lange)

Speziell für dein jetzt bestehendes Problem kann ich dir mal folgende Alternative zur Verfügung stellen: Speicher doch das Mittel erstmal in einer Variablen.

SQL-Code:

DECLARE @test AS float
SELECT @test = avg(cast(pid AS float)) FROM testtable
SELECT * FROM testtable WHERE pid >= @test ORDER BY pid

Getestet unter M$SQL 7.0 – funkt

Hoffe, ein wenig gehilft zu haben...

Gruß
Armin

[Tomektor]

AVE NEUROMANCER!

Danke für die Antwort und den Tipp!
Wenn es darum geht verschachtelte SELECTs auszuführen, mache ich es so wie Du es vorgeschlagen hast!

In dem Fall geht es aber nicht, denn es ist ein SELECT und ein UPDATE.
Das Ergebnis der SELECT Anweisung wird über eine Schlaufe geschickt um dann bei bestimmten Sätzen ein UPDATE (bzw. Edit) auszuführen.
Ob ein UPDATE ausgeführt wird, entscheidet der Benutzer in dem er auf ABBRECHEN bzw. BESTÄTIGEN klickt.

Für den Extremfall werde ich folgendes machen (doch aus Sicherheitsgründen darf ich das eigentlich nicht... - die Vorgabe lautet: "keine Zwischenspeicherung!!"):

Die "Antworten" aus der Anzeige, also Klicks auf "Abbrechen" oder "Bestätigen" werden in einem Array gesammelt, um später (nach dem alle Fenster zugemacht wurden) eine Schleife über das Array laufen zu lassen und die zu ändernden Datensätze dann ändern.
Es wäre aber wirklich mehr als Schei... denn das gesamte alte Programm müßte an die MySQL Eigenart angepasst werden.

Es wirde vielleicht die letzte Alternative sein, wenn keine andere Lösung gefunden wird, doch ich hoffe jemand hat noch eine Idee?!
Wäre Klasse! :P


Übrigens ich war bis jetzt von der MySQL-Datenbank begeistert. In Punkto Geschwindigkeit unter Unix ist es wahrscheinlich das schnellste was zu finden ist! Sie ist auch sehr zuverlässig. Bis jetzt habe ich mit ihr nur auf Webservern über PHP gearbeitet und da gibt es nichts besseres! In der WinWelt über ODBC bleibt größtenteils der Preis der Vorteil, viel mehr aber auch nicht.
Das Problem (welches micht zum ersten mal betrifft) ist die eingeschränkte SQL-Sprache...

Zu MSSQL kann ich nur sagen ich habe diese Datenbank vorgestern kennengelernt und finde sie (zumindest heute) nicht berauschend. Mal schauen ob sich das ändert... :wink:

Also Danke für die Antwort und hoffe auf weitere.

Gruß!

Tomektor

P.S. Meine letzten Überlegungen gehen dahin, dass der Fehler an dem ODBC Treiber zu MySQL (oder an ADO) liegen müßte, denn ähnliche Aufgaben lassen sich mit einer Direktverbindung zu MYSQL mit PHP kinderleicht lösen...

[Neuromancer]

Hallo Tomektor,

ich werde mal schauen, ob ich bei Google ne Hilfe-Datei zu MySQL finde. Am liebsten wäre mir ne komplette Befehlsübersicht, dann kann ich mehr dazu sagen.

Was mich an MySQL halt immens stört, dass es (noch) keine Stored Procs ausführen kann (ab Version 5 dann, denke ich). Und die sind – zumindest für mich – das Herz der SQL-Programmierung.

Mit der Speed ist das so eine Sache. Ab September werde ich unter der Obhut einer Pervasive-Datenbank arbeiten. Und natürlich – wie könnte es anders sein – behauptet Pervasive, sie seien die schnellsten. Wie dem auch sei…
Die Kohle sitzt nimmer locker, aggressives Marketing ist angesagt. Und ich denke, seit das Gerücht(?) umgeht, SAP würde sich auf MySQL einlassen, kann ich mir vorstellen, dass MySQL da auch ganz schön die Werbetrommel rührt…

Aber zurück zum Problem:
Kannst du mal das komplette SQL-Statement des UPDATE/SELECT posten?

Zu ODBC: über ODBC das Ganze zu lösen, könnte natürlich schon einschränkend wirken. Gibt es denn für MySQL keinen "richtigen" OLE DB Provider?
Mit einem solchen würden sich sicher nicht nur einige Statements mehr ausführen lassen, sondern in punkto Geschwindigkeit dürfte das auch noch mal so richtig boosten.

Über ADO kann ich nicht klagen, bis jetzt hat es eigentlich sehr gute Dienste geleistet (von den typischen COM-Stolperfallen mal abgesehen)

Gruß
Armin

[Jelly]

Zitat:

Zitat von Neuromancer

Gibt es denn für MySQL keinen "richtigen" OLE DB Provider?

Doch gibts, und zwar hier.

Zitat:

Zitat von Neuromancer

Mit einem solchen würden sich sicher nicht nur einige Statements mehr ausführen lassen, sondern in punkto Geschwindigkeit dürfte das auch noch mal so richtig boosten.

Skurielerweise ist es mit diesem OLDDB Treiber grotten langsam. In einem lokale Netz fällts vielleicht nicht so auf, greifst du jedoch über z.B. ISDN auf eine Internet Datenbank zu, können dann bei den einfachsten Select Abfragen schon einige Sekunden vergehen. Ich hab keine Ahnung warum, aber es werden Unmengen an Daten übertragen.

Ah ja, noch was zu den Subqueries: Das geht bei MySQL nicht (zumindest nicht in der 4-er Version).

Gruss,
Tom