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

[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.