Fehler bei ADOTable.Post

[Peter Pawlowski]

Hallo zusammen - ich hatte ein ähnliches Problem. Bei mir funktionierte auf meinem Entwicklungsrechner alles wunderbarst. Auf unseren Terminalservern, auf denen das Programm dann eingesetzt wurde hatte ich die gleiche Fehlermeldung wie du.

Bei mir hat es geholgen die ODBC Einstelleung für die Datenbank (ODBCAD32.exe) exakt an die des Entwicklungsrechners anzupassen (also Codepage etc.)

[Bernhard Geyer]

Zitat von Peter Pawlowski:

Hallo zusammen - ich hatte ein ähnliches Problem. Bei mir funktionierte auf meinem Entwicklungsrechner alles wunderbarst. Auf unseren Terminalservern, auf denen das Programm dann eingesetzt wurde hatte ich die gleiche Fehlermeldung wie du.

Bei mir hat es geholgen die ODBC Einstelleung für die Datenbank (ODBCAD32.exe) exakt an die des Entwicklungsrechners anzupassen (also Codepage etc.)

Über ADO und ODBC auf eine Access-Datenbank zugreifen wäre wohl reichlich umständlich.
Access ist neben dem MS SQL-Server die einzige DB die man sinnvollerweise direkt mit dem vorhandenen ADO-Treiber anspricht und keinen Umweg über ODBC wählt.

[arnof]

Hi,

ich arbeite in vielen Großprojekten mit der ADO und verschiedenen SQL-Servern. Die ADO hat so ihre Eigenheiten mit Postfehler unlustigen Löschfehlern.

Meine Lösung die bei tausenden Kunden nach Jahren des reifens problemfrei läuft ist, das ich mit eigene Komponenten gebastelt habe, die diese ganzen Eigenheiten abfangen:

z.B. gibt es die PostError, dort legt man eine Funktion hin, die das SQLStatemant manuell zusammenbastelt und dann via Command Komponente abschickt.


Dies ist aber nicht trivial und geht weit über die Möglichkeiten des Formum hinaus

Nur mal damit man den Anfang findet:


procedure TADOTable.PostError(DataSet: TDataSet; E: EDatabaseError; var Action: TDataAction);

.....

if State=dsInsert then begin
if Trim(xInsertField)<>'' then begin
c.CommandText:='INSERT INTO '+c1+XADOTable.TableName+c2+' ('+xInsertField+') VALUES ('+xInsertValue+')';

....

c.CommandText:='UPDATE '+ADOTable.TableName+' SET ....'+xUpdate+' WHERE '+ADOTable.FieldDefs[0].Name+'='+MakeSQLValue(FieldByName(XADOTable.Field Defs[0].Name));

[Bernhard Geyer]

Zitat von arnof:

ich arbeite in vielen Großprojekten mit der ADO und verschiedenen SQL-Servern. Die ADO hat so ihre Eigenheiten mit Postfehler unlustigen Löschfehlern.

Kann ich nicht bestätigen. Ich vermute das du Fehler/Problem mit ADOExpress/dbGo hast.

Zitat von arnof:

c.CommandText:='INSERT INTO '+c1+XADOTable.TableName+c2+' ('+xInsertField+') VALUES ('+xInsertValue+')';

....

c.CommandText:='UPDATE '+ADOTable.TableName+' SET ....'+xUpdate+' WHERE '+ADOTable.FieldDefs[0].Name+'='+MakeSQLValue(FieldByName(XADOTable.Field Defs[0].Name));

Autsch. Du baust doch wohl nicht wirklich deine SQL-Statement so zusammen ohne parameter zu verwenden.
Da hattest du wohl noch kein Sicherheits-Audit in diesem Bereich?

[arnof]

Parameter: je nach MySQL Treiber Version gehen die manchmal komplett nicht, kommt dort ständig vor nach Treiberupdates

[jobo]

auch aus Erfahrung:
Prüfe mal die Daten, die Du eintragen willst. Lieblingsfehler sind falsche Datumswerte (Bereichsfehler)- hier nicht verwendet.
Mglw. noch Bereichsfehler bei Currency oder Konvertierungsprobleme Unicode..

[Bernhard Geyer]

Zitat von arnof:

Parameter: je nach MySQL Treiber Version gehen die manchmal komplett nicht, kommt dort ständig vor nach Treiberupdates

Für Mysql gibts schöne Lösungen die alles in Delphi implementieren (die DevArt-Kompos sind sehr zu empfehlen).
Ein Umweg über ADO ist hier neben den Fehler der Treiber auch bezüglich der GPL-Falle problematisch.

[arnof]

Klar gibts die meine kann aber alle Datenbank, die einen Treiber haben mit dem 100% gleichen Delphicode ..... und ich konnte damit meine über 500.000 Zeilen App die mal mit der BDE lief übernehmen ohne alles neu zu machen

Deshalb arbeite ich noch auf D5 werde aber diesen Monat mal XE2 als Produktivsystem wechsen. Für Xe3 und X4 fehlen mir noch zuviele Komponenten ....

[Bernhard Geyer]

Zitat von arnof:

Klar gibts die meine kann aber alle Datenbank, die einen Treiber haben mit dem 100% gleichen Delphicode

Sicher? Wie handhabst du die unterschiede in den SQL-Dialekten? Wie schauts mit alten Oracle-Versionen aus welche noch nicht den normalen JOIN-Syntax können?

Zitat von arnof:

..... und ich kommte damit meine über 500.000 zeilen App die mal mit der BDE lief übernehmen ohne alles neu zu machen

Halte dagegen: 1,8 Mio. Quellcodezeilen (Mit Zusatzkomponenten), DB-Spezifischer Teil für MySQL ist ca. 2000 Zeilen, Bei Oracle ebenfalls.
Datenbanken sind bis zu 50 GB groß. Lösung über Bridge-Pattern.

[arnof]

[QUOTE=Bernhard Geyer;1217783]

Zitat von arnof:

Klar gibts die meine kann Sicher? Wie handhabst du die unterschiede in den SQL-Dialekten? Wie schauts mit alten Oracle-Versionen aus welche noch nicht den normalen JOIN-Syntax können?

das macht meine Komponente, die liegt tief im System incl. Bug aus ADODB und den DB Units entfernt bzw abgefangen

Zitat von arnof:

..... und ich kommte damit meine über 500.000 zeilen Halte dagegen: 1,8 Mio. Quellcodezeilen (Mit Zusatzkomponenten), DB-Spezifischer Teil für MySQL ist ca. 2000 Zeilen, Bei Oracle ebenfalls.

also aller Quellcode ist aktuell bei 1.2 mil Zeilen, da sind aber auch die Komponentenquellcodes dabei.

Zitat:

Datenbanken sind bis zu 50 GB groß. Lösung über Bridge-Pattern.

in Spitzenzeiten über 120 Kaufhäuser in der Zentrale zusammengefasst