Delphi, ADO, MySQL und ein ganz böser Parameterfehler...

[Guido R.]

Hallo Allerseits !

Ich habe (mit Delphi 5 SP1) ein Programm geschrieben, dass mittels ADO/ODBC auf eine MySQL-Datenbank zugreift. Im Programm selbst benutze ich dazu u.a. ADOCommands, deren SQL-Anweisungen mittels Parameter Daten zugewiesen werden.

Dies funktioniert auch wunderbar, so lange entweder eine (alte) MDAC 2.80 oder eine (alte) MyODBC 3.51.14 oder noch älter installiert sind.

:coder2:

Wenn sowohl MDAC in der Version 2.81.1117.0 (Teil des XP SP2) als auch MyODBC in der Version 3.51.15 / 3.51.16 vorhanden sind, erhalte ich folgende Fehlermeldung :

"Ein Parameterobjekt ist nicht ordnungsgemäß definiert. Inkonsistente oder unvollständige Informationen wurden übergeben."

Wenn ich die SQL-Anweisung manuell zusammenbastel und keine Parameter verwende, funktioniert es;
jedoch kann das keine Lösung sein, da ich sehr häufig Parameter in diesem Programm verwende.

Es kann im übrigen auch nicht daran liegen, dass NULL-Werte unbekannten Typs sind, da auch Aufrufe abstürzen, die definitiv keinen NULL-Wert enthalten.

Tritt dieses Problem auch mit Delphi 7 oder neuer auf ?
Irgendwelche Ideen, wie ich das ganze korrigieren kann, ohne alle Parameter herauszunehmen oder alte Treiber vorauszusetzen ??? :gruebel:
(Ich kann einem Kunden ja wohl schlecht erzählen, er solle sich nur alte Treiber installieren...)

Gruß
Guido

[mkinzler]

Wie sieht die Abfrage aus?

[Guido R.]

Z.B. so :

SQL-Code:

insert into products_description(
   products_id, 
   language_id, 
   products_name, 
   products_description, 
   products_viewed
   ) values (
   :products_id, 
   :language_id, 
   :products_name, 
   :products_description, 
   :products_viewed)
ON DUPLICATE KEY UPDATE
   products_name=:name1, 
   products_description=:description1

Parameterübergabe mit :

Delphi-Quellcode:

{...}
ADOCmd.Parameters.ParamByName('products_id').Value                   := ID;
{...}

[Bernhard Geyer]

Zitat:

Zitat von Guido R.

Tritt dieses Problem auch mit Delphi 7 oder neuer auf ?

Wenn der Fehler bei anderen Treiberversionen nicht auftritt ist das kein Delphi-Fehler sondern (höchstwahrscheinlich) ein Problem der (DLL-Hölle-) Kette ADO - ODBC - MyODBC

Zitat:

Zitat von Guido R.

Irgendwelche Ideen, wie ich das ganze korrigieren kann, ohne alle Parameter herauszunehmen oder alte Treiber vorauszusetzen ??? :gruebel:
(Ich kann einem Kunden ja wohl schlecht erzählen, er solle sich nur alte Treiber installieren...)

Und wieso zwingst du deinem Kunden überhaupt irgendwas zu installieren? Für Delphi gibt es z.B. die sehr guten MyDAC-Komponenten. Damit ist mir vollkommen egal ob der Kunde irgendwelche MyODBC, ODBC oder ADO-Updates sich (zwangsweise) installiert. Deine Treiber (und damit potentielle Fehlerquelle) ist:

Anwendung -> ADO-Express/dbGO -> ADO -> OLE DB für ODBC -> ODBC -> MyODBC -> MySQL-Server

mit MyDAC verkürzst du diese potentielle Fehlerquelle auf

Anwendung -> MyDAC -> MySQL-Server


Aber zu deinem Problem: Nutzt du evtl. TADOTable/TADOQuery? Bei Verwendung von TADODataSet sind weniger Fehler zu erwarten (falls der Fehler doch in der ADOExpress/dbGo-Implementierung liegen sollte).

[shmia]

Man muss darauf achten, dass [TParameter].DataType auf den korrekten Datentyp eingestellt ist.
Bei einer Änderung an der SQL Anweisung versucht die VCL, über den Treiber den korrekten Datentyp zu ermitteln.
Dies kann in vielen Fällen schiefgehen (z.B. bei komplexen Abfragen oder nicht-standard SQL wie in deinem Fall) und dann muss man von Hand eingreifen.
Wenn es ein String-Datentyp ist, muss auch [TParameter].Size korrekt eingestellt werden.

[Guido R.]

@ B.Geyer

Zitat:

Und wieso zwingst du deinem Kunden überhaupt irgendwas zu installieren? Für Delphi gibt es z.B. die sehr guten MyDAC-Komponenten. Damit ist mir vollkommen egal ob der Kunde irgendwelche MyODBC, ODBC oder ADO-Updates sich (zwangsweise) installiert.

Die Komponenten sind mir bekannt und ich würde sie auch gerne verwenden. Leider sieht das Projekt vor, später auf andere Datenbanken angewendet zu werden. Daher sind alle SQL-Befehle in JvMultiStringHoldern (Jedi sei Dank) gespeichert, so dass für die Varianzen in den SQL-Dialekten lediglich der richtige StringHolder gewählt werden muss.

Zitat:

Aber zu deinem Problem: Nutzt du evtl. TADOTable/TADOQuery? Bei Verwendung von TADODataSet sind weniger Fehler zu erwarten (falls der Fehler doch in der ADOExpress/dbGo-Implementierung liegen sollte).

Nein - Für Update/Insert-Operationen verwende ich die ADOCommand, ansonsten das BetterADODataset.

[mkinzler]

Ado als Bridge-Pattern-Ersatz kannst du vergessen. ODBC erst recht.
Welceh DBMS sollen zusätzlich unterstützt werden?

[Bernhard Geyer]

Zitat:

Zitat von mkinzler

Ado als Bridge-Pattern-Ersatz kannst du vergessen. ODBC erst recht.
Welceh DBMS sollen zusätzlich unterstützt werden?

Da nimmt mir einer die Worte aus dem Mund bzw. den Fingern :-)

[Guido R.]

@shmia

Ich habe mal probiert allen Parametern den Typ zuzuweisen

Delphi-Quellcode:

{...}
ADOCmd.Parameters.ParamByName('products_id').DataType                := ftInteger;
{...}

Das hat nicht ausgereicht - Die zus. Zuweisung der Stringgrößen probiere ich gleich mal aus.

Seltsam ist das das bislang alles wunderbar funktioniert hat und nur die Kombination aus aktuellen ADOs und aktueller MyODBC zu problemen führt...

[Guido R.]

Zitat:

Ado als Bridge-Pattern-Ersatz kannst du vergessen. ODBC erst recht.
Welche DBMS sollen zusätzlich unterstützt werden?

Der Grundgedanke war bei Kunden evtl. vorhandene DBMS weiter zu nutzen. Konkret ins Auge gefasst war da u.a. MSSQL - Weitere DBs natürlich nicht ausgeschlossen...

Wie bereits gesagt - bislang hatten wir keine Probleme damit - erst die Kombi aus neuen Treibern führte zu der Meldung.

[Bernhard Geyer]

Zitat:

Zitat von Guido R.

Wie bereits gesagt - bislang hatten wir keine Probleme damit - erst die Kombi aus neuen Treibern führte zu der Meldung.

Genau deshalb sollte man ADO für Nicht MS SQL Server und Access meiden wie der Teufel das Weihwasser. Du musst spätestens alle 4 Wochen (Monatliches MS-Updates) beten ob nicht irgendein Treiberupdate deine fragile Kette

Anwendung -> ADO-Express/dbGO -> ADO -> OLE DB für ODBC -> ODBC -> MyODBC -> MySQL-Server

zum Einsturz bringt. Da MS eh schon alle Kapazitäten in den Bereich .NET verlagert hat und MySQL eh sowas egal ist solange Du nicht genügend Geld in die Hand für gekauften Support in die Hand nimmst wirst du keinen bei diesen Firmen finden den das überhaupt interessiert.

[Guido R.]

Problem lokalisiert !!!

Shmia hat Recht !!! :thumb:
Seitdem ich den Strings einen Wert für ihre Größe vorgegeben habe, funktioniert es... :wall:

(... na das wird jetzt lustig - das Projekt ist nicht gerade klein)

@Bernhard Geyer & mkinzler :

Zitat:

Ado als Bridge-Pattern-Ersatz kannst du vergessen. ODBC erst recht.

Wie würdet Ihr da vorgehen ???
Vorgaben :
1. Es darf nicht zu teuer an Fremdkomponenten werden
2. Das Projekt sollte "offen" sein für weitere DB-Systeme
3. Die Implementierung neuer DB-Verbindungen sollte nicht zu aufwendig werden

[mkinzler]

Du mußt den datenbankspezifischen Code in eigene Units aulagern. (pro DBMS eine Unit)

[Bernhard Geyer]

Zitat:

Zitat von Guido R.

1. Es darf nicht zu teuer an Fremdkomponenten werden

Was ist teuer? Crlab kostete uns < 1000 € und das war bei uns kein Problem. Sparten uns jedliche Zeit bezüglich Treibeinstallationsprobleme

Zitat:

Zitat von Guido R.

3. Die Implementierung neuer DB-Verbindungen sollte nicht zu aufwendig werden

Pro DB ca. 1500 - 2000 Zeilen Code - bei über 1 Mio. Quellcodezeilen.