Ado/ODBC -> Bin-Daten werden beim Insert/Update verändert!?

[luwo]

Hallo DP-Freunde,

habe gerade ein sehr seltsames Problem und brauche eure Hilfe.

Es werden Daten über ADO/ODBC (geht nicht anders, ist eine Vorgabe) in eine Tabelle eines SQL-Servers (Microsoft SQL-Server 2005/Express) geschrieben,
beim Rauslesen sind diese nicht mehr mit den Originaldaten identisch!
Sie werden verändert! (reproduzierbar, siehe unten)

Habe die Daten in der DB mit unterschiedlichen Methoden überprüft, die Daten sind tatsächlich verschieden zu denen die im Statement angegeben wurden.
Irgendwas geht beim Schreiben in die DB schief.

Das Feld der Tabelle ist als "Text" deklariert (also ein Blob).
Die Inhalte werden über einen String (MyKontent), in dem Binärdaten drinstehen wie folgt in die DB übertragen

Delphi-Quellcode:

  
 with ADOCommand1 do
  begin
   Parameters.ParamByName('Kontent').Value:= MyKontent;
   Parameters.ParamByName('ID').Value:= ID;
   Execute;
  end;

Mit diesem Command-Statement:UPDATE Testtabelle SET Kontent=:Kontent WHERE ID=:ID Hab auch schon folgendes probiert:

Delphi-Quellcode:

  
 with ADOCommand1 do
  begin
   Parameters.Clear;
   Parameters.CreateParameter(':Kontent',ftMemo, pdInput, MAXINT, MyKontent); 
   Parameters.CreateParameter(':ID',ftInteger, pdInput, MAXINT, ID); 
   Execute;
  end;

Ich vermute, es hat irgendwas mit ftMemo zu tun, aber leider nimmt ADOCommand1 in diesem Fall nichts anderes an
Bei ftBlob kommt eine Fehlermeldung:

Zitat:

'[Microsoft][ODBC SQL Server Driver][SQL Server]Operandentypkollision: image ist inkompatibel mit text'

Der Fehler tritt immer dann auf, wenn
1) Die Daten > 8000Byte lang sind UND
2) ein "$5c $0a" (also ein Escape-Zeichen und ein $0a) im Datenpaket vorkommt.

Die Daten werden verändert, indem die beiden Bytes "$5c $0a" einfach gelöscht werden -> und das ist tatsächlich reproduzierbar!

Hat jemand eine Idee woran das liegen kann oder einen Tipp wie man das Insert/Update anders machen könnte?
Vielleicht sagt einem ja das "\$0a" irgendwas oder die Länge von 8000Byte?


Vielen Dank für Hilfe oder sachdienliche Hinweise!


PS: Benutze Delphi7/prof

Grüße Luwo

[Bernhard Geyer]

Gehst du wirklich über ADO auf einen ODBC-Eintrag?

8000 Bytes würde mir was sagen wenn die Daten nicht in eine (n)text-Spalte geschrieben würde, da beim MS SQL-Server eine Datenzeile AFAIK maximal 8060 Bytes aufnehmen kann. Ich würde auch alternativ mal probieren ohne ADOExpress/dbGo zu arbeiten und nur die ADO-Interfaces direkt zu verwenden. Alternativ (wenn wirklich ADO->ODBC verwendet wird) mit ADO direkt auf die Datenbank zu gehen. Evtl. stirbt ja langsam der Zugriff über ODBC auf MS SQL-Server langsam den Windows-Update-Tod.

[alzaimar]

Hi,

Strings (VarChar) dürfen beim MSSQL-Server nur 8000+x Zeichen lang sein. Du schreibst die Daten als String in die DB. Daher die Restriktion. Verwende einen Stream. Wie das bei Parametern geht, weiss ich auch nicht, aber vermutlich wird 'LoadFromStream' sowie das korrekte Setzen der Datentyp-Eigenschaft zum Erfolg führen.

Schau Dir doch mal über den Profiler an, wie ein korrektes UPDATE aussieht. Verwende dazu eine TADOTable und schieb die Daten über ein TBlobField rein. Beim POST wirst Du dann das richtige UPDATE-Format/Syntax im Profiler sehen. Dann bastelst Du Dir eine eigene Routine, die den UPDATE-Befehl korrekt zusammenfriemelt und fettig.

Weiterhin musst Du bedenken, das ein TEXT-Feld nicht beliebige Werte annehmen kann. Im Zweifelsfall nimm ein Image.

[luwo]

Zitat von Bernhard Geyer:

8000 Bytes würde mir was sagen wenn die Daten nicht in eine (n)text-Spalte geschrieben würde, da beim MS SQL-Server eine Datenzeile AFAIK maximal 8060 Bytes aufnehmen kann.

"Abgeschnitten" im eigentlichen Sinn wird ja nix, es werden einfach nur die "5c 0a"-Byte-Kombinationen gelöscht!
Und eben NUR dann, wenn mindestens 8000 Byte da sind.

Zitat von alzaimar:

Weiterhin musst Du bedenken, das ein TEXT-Feld nicht beliebige Werte annehmen kann. Im Zweifelsfall nimm ein Image.

ja, es hat alles nix geholfen, wir haben uns jetzt zum "image" durchgerungen, da wird definitiv NIX geändert.

Ist zwar eigentlich mehr ein "Workaround", aber funktioniert.


Wobei der Fehler selbst schon ziemlich kurios ist, auch weil "5c 0a" eigentlich doch nix UniCode zu tun hat, oder?!


Aber trotzdem vielen Dank an euch beide!

Grüße Luwo