Fehler bei ADOTable.Post

[Detlef]

Hallo Delphianer,
wenn ich in einem Zyklus mehrere Sätze in eine MDB-Tabelle schreibe
bekomme ich beim Post des 2. Satzes die Fehlermeldung:

'Fehler bei einem aus mehreren Schritten bestehenden Vorgang. Prüfen
Sie die einzelnen Statuswerte.'
Der Code sieht etwa so aus:

Delphi-Quellcode:

while not adodataset1.Eof do begin
      buchform.adotable1.append;
      buchform.ADOTable1['KNR']:=adodataset1['KNR'];
      tempbetrag:=adodataset1['Betrag']*100;
      strintdm(tempbetrag,stempbetrag,0);
      buchform.ADOTable1['Betrag']:=stempbetrag;
      buchform.ADOTable1['Empf']:=adodataset1['Empf'];
      buchform.ADOTable1['Text']:=adodataset1['Text'];
      buchform.ADOTable1.Post;
      adodataset1.next;
   end;

Die Tabellendefinition:

Delphi-Quellcode:

object ADODataSet1KNR: TStringField
  DisplayWidth = 40
  FieldName = 'KNR'
  Size = 40
end
object ADODataSet1Betrag: TCurrencyField
  FieldName = 'Betrag'
end
object ADODataSet1Empf: TWideStringField
  FieldName = 'Empf'
  Size = 50
end
object ADODataSet1Text: TWideStringField
  FieldName = 'Text'
  Size = 50

end

Der erste Satz wird ordnungsgemäß gespeichert. Erst ab dem 2.
passierts dann.

Wer hat einen Tip ?

Gruß Detlef

[edit=MrSpock]Code Tags eingefügt. Mfg, MrSpock[/edit]

[Matt]

Die Fehlermeldung kann ziemlich viel bedeuten, ich kenne Sie im Zusammenhang mit ASP und ADO und ich HASSE sie, weil so nichts aussagend. Ich würde ADO veranlassen dir eine konkrete Fehlermeldung zu generieren. Habe hier im Forum diesen Beitrag gefunden. Würde mal versuchen so den Fehler genauer zu betiteln.

ADO-Fehler (bestehend aus mehreren Schritten) anzeigen

[Detlef]

Hallo Matt,
habe das nun gemacht und bekomme Zusatzinfo

#-2147217887 Microsoft Cursor Engine.

Wo finde ich dazu etwas?

Detlef

[Gollum]

Hallo,

so ganz schlau werde ich aus Deinem Code nicht. Was mir aber aufgefallen ist, dass Du das Dataset in einer Schleife durchläufst, die Daten aber mit Append in die Tabelle schreibst???? Noch dazu, was soll das Dataset.Next am Schluß???

Lasse einmal die While-Schleife und das Next weg, dann sollte es gehen. Ansonsten würde ich Dir eine Query empfehlen und die Daten mit "INSERT INTO" in die Tabelle schreiben.

[Matt]

Hast Du eventuell bei deiner ADO-Connection etwas verändert bei "CursorLocation" z.B.?
Steht die vielleicht auf "clUseServer"?

Nimm mal zum testen alle Default-Werte der Connection!

Gruß Matt

[Detlef]

Hallo Gollum,
ich habe ein Dataset, dessen Sätze ich in die TABLE übernehmen möchte.
Deshalb die Schleife und das DATASET.NEXT. Normalerweise mache ich solche Dinge (erfassen und datensatzweise in eine TABLE übernehemen)
ja auch und es klappt. Nur in diesem Fall passierts beim Post oder
beim Append des nächsten Satzes in der Schleife. Ich habe schon auf
AUTOINC-Feld getippt oder auf das Betragsfeld im BCD-Format. Aber
richtig eingrenzen kann ich es nicht.
Hallo Matt,
ich benutze CONNECTIONSTRING mit
CURSOR-Location=clclient
Cursortype=ctkeyset.
Habe nichts an den Standards geändert.

Ich bin momentan

Rudi Ratlos :wall:

Detlef

[mikhal]

Du verwendest als Feldnamen einen Bezeichner ('TEXT'). Eventuell hängt sich die Jet an dieser Stelle auf.

Text ist ein Feldtyp in der MS Jet.

Grüße
Mikhal

[Detlef]

Ist leider mit anderem Feldnamen auch nicht besser.
Schade (hatte so gehofft)
Detlef

[Gollum]

Hallo,

ich habe mir Deinen Code noch einmal angeschaut und dabei ist mir aufgefallen, dass Du in Deinem Beispiel die Felder und nicht die Feldinhalte zuweist. Vielleicht hilft es, wenn Du Deinen Code folgendermassen umänderst:

Delphi-Quellcode:

while not adodataset1.Eof do 
begin 
  buchform.adotable1.append; 
  buchform.ADOTable1['KNR'].AsString:=adodataset1['KNR'].AsString; 
  tempbetrag:=adodataset1['Betrag'].AsFloat*100; 
  strintdm(tempbetrag,stempbetrag,0); 
  buchform.ADOTable1['Betrag'].AsFloat:=stempbetrag; 
  buchform.ADOTable1['Empf'].AsString:=adodataset1['Empf'].AsString; 
  buchform.ADOTable1['Text'].AsString:=adodataset1['Text'].AsString; 
  buchform.ADOTable1.Post; 
  adodataset1.next; 
end;

[edit]
Da ich nicht sicher weiss, ob obiges Beispiel funktioniert, könntest Du noch evtl. folgendes probieren:

Delphi-Quellcode:

  ...
  buchform.ADOTable1.FieldByName('KNR').AsString:=adodataset1.FieldByName('KNR').AsString; 
  ....

[/edit]

[Detlef]

Hallo Gollum,

Dein letztes Beispiel hat dahingehend geholfen, daß es nun erst beim
dritten Satz bumst. Das ist ja interessant!
Kann so etwas auch mit dem Autoincrementfeld etwas zu tun haben?
Ich stehe so richtig auf dem Schlauch!

Detlef

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

Zitat von Peter Pawlowski (Beitrag 1217752)

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:

Zitat von arnof (Beitrag 1217757)

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:

Zitat von arnof (Beitrag 1217757)

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 :shock:

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

Zitat von arnof (Beitrag 1217775)

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

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 8-)

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:

Zitat von arnof (Beitrag 1217782)

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:

Zitat von arnof (Beitrag 1217782)

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

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:

Zitat von arnof (Beitrag 1217782)

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:

Zitat von arnof (Beitrag 1217782)

..... 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 :lol: