MS SQL CHAR(300) Feld übernehmen

[rokli]

Guten Morgen alle zusammen!

In einer IBM DB2 ist ein Char - Feld in der Länge von 300 Zeichen definiert worden. Dieses Feld wird durch Progs auf einer System I mit Ziffern (und in seltenen Fällen am Ende mit Buchstaben) gefüllt.
Daneben gibt es eine MS SQL Datenbank, in der ebenfalls ein Feld in der Länge CHAR(300) definiert ist.

Nun muss ich dieses Feld von der DB2 in die MS SQL bringen! Dazu wollte ich:

Delphi-Quellcode:

qryIns := 'INSERT tblMS (chrFeld300) VALUES (' + qryDB2.FieldByName('FELD300').AsVariant + ')';
qryIns.ExecSQL;

die Übertragung machen. Delphi XE2 interpretiert das Ganze aber immer als numerischen Wert, sagt mir, dass die Zahl zulang ist und wirft folgende Exception:

Delphi-Quellcode:

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt Barg_Info.exe ist eine Exception der Klasse EDBEngineError mit der Meldung 'Allgemeiner SQL-Fehler
[Microsoft][ODBC SQL Server Driver][SQL Server]The number
'010014422006620121026000000045135066105329500006000010012000000010605965670' is out of the range for numeric representation
(maximum precision 38).
[Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near 'Front'.' aufgetreten.
---------------------------
Anhalten   Fortsetzen   Hilfe   
---------------------------

Hat jemand eine Idee, wie ich das bewerstelligen kann?

Danke und viele Grüße
Rolf

[mkinzler]

Versuche es mal mit (SQL-)Parametern

[Bernhard Geyer]

Wenn du deinen als Zahl in den SQL-String legst ist das keine Wunder ....

Mach am besten auch gleich das was mkinzer vorschlägt.
Sonst hast du probleme wenn deine DB2-Datensatz sowas wie "''; DELETE FROM tblMS; //" beinhalten sollte ...

[rokli]

Hallo

und vielen Dank - das werde ich mal testen!

Rolf

[p80286]

Wenn ich jetzt wüßte wie Du Dein Programm auf ODBC zugreifen läßt...
aber die meisten (mir bekannten) Schnittstellen unterstützen .asstring, das würde unter Umständen besser funktionieren als das .asVariant.
Davon abgesehen Parameter !

Gruß
K-H

[Sir Rufo]

Das Problem ist nicht wegen AsVariant und lässt sich auch mit AsString nicht beheben.
Denn das daraus resultierende Statement lautet so:

Code:

INSERT INTO tblMS (chrFeld300) VALUES (010014422006620121026000000045135066105329500006000010012000000010605965670)

Für dieses Statement wird der Wert als Zahl interpretiert und diese Umwandlung schlägt eben fehl (genau das sagt ja auch die Fehlermeldung).
Da SQL etwas tolerant ist, kann es auch eine Zahl in ein Char-Feld speichern.

Hier soll aber keine Zahl, sondern eine Ziffernfolge gespeicht werden und das ist ein String/Char/Varchar.

Dann sollte man dem Statement dieses auch mitteilen: "Hallo, das ist bitte als Zeichenfolge zu verstehen."

Code:

INSERT INTO tblMS (chrFeld300) VALUES ("010014422006620121026000000045135066105329500006000010012000000010605965670")

Und damit alles im Leben einfacher, schneller - und viel wichtiger sicherer - wird, sind Parameter hier unbedingt zu empfehlen.

Code:

INSERT INTO tblMS (chrFeld300) VALUES ( :chrFeld300 )

oder in Delphi

Delphi-Quellcode:

qryIns.SQL.Text := 'INSERT INTO tblMS (chrFeld300) VALUES ( :chrFeld300 )';
// teilweise gibt es auch noch eine spezielle Methode zum Vorbereiten
// hängt aber von der Zugriffskomponente ab

// qryIns.Prepare;

while not qryDB2.EOF do
begin
  qryIns.ParamByName( 'chrFeld300' ).Value := qryDB2.FieldByName('FELD300').AsVariant;
  qryIns.ExecSQL;
  qryDB2.Next;
end;

// qryIns.Unprepare;

Das ist dann nicht nur sicherer, einfacher sondern vor allem erheblich schneller, da der Server jetzt schon weiß, was er machen soll und kann sich darauf vorbereiten (prepare). Es werden nur noch die reinen Daten vom Client übertragen, weil die Anweisung dem Server ja schon bekannt ist.

[Bernhard Geyer]

Zitat:

Zitat von Sir Rufo (Beitrag 1188328)

Dann sollte man dem Statement dieses auch mitteilen: "Hallo, das ist bitte als Zeichenfolge zu verstehen."

Code:

INSERT INTO tblMS (chrFeld300) VALUES ("010014422006620121026000000045135066105329500006000010012000000010605965670")

Und damit alles im Leben einfacher, schneller - und viel wichtiger sicherer - wird, sind Parameter hier unbedingt zu empfehlen.

Und wenn man es direk angiebt sollte man die SQL-Hochkommas verwenden sonst krachte es gleich wieder :-)

[p80286]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1188330)

Zitat:

Zitat von Sir Rufo (Beitrag 1188328)

Dann sollte man dem Statement dieses auch mitteilen: "Hallo, das ist bitte als Zeichenfolge zu verstehen."

Code:

INSERT INTO tblMS (chrFeld300) VALUES ("010014422006620121026000000045135066105329500006000010012000000010605965670")

Und damit alles im Leben einfacher, schneller - und viel wichtiger sicherer - wird, sind Parameter hier unbedingt zu empfehlen.

Und wenn man es direk angiebt sollte man die SQL-Hochkommas verwenden sonst krachte es gleich wieder :-)

ÄH?
Hat er doch? ist doch MS!?

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von p80286 (Beitrag 1188337)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1188330)

Zitat:

Zitat von Sir Rufo (Beitrag 1188328)

Dann sollte man dem Statement dieses auch mitteilen: "Hallo, das ist bitte als Zeichenfolge zu verstehen."

Code:

INSERT INTO tblMS (chrFeld300) VALUES ("010014422006620121026000000045135066105329500006000010012000000010605965670")

Und damit alles im Leben einfacher, schneller - und viel wichtiger sicherer - wird, sind Parameter hier unbedingt zu empfehlen.

Und wenn man es direk angiebt sollte man die SQL-Hochkommas verwenden sonst krachte es gleich wieder :-)

ÄH?
Hat er doch? ist doch MS!?

Gruß
K-H

Zum Einen das und zum Anderen werden von einigen DBMS auch beide Varianten unterstützt " oder '
Das ist aber obsolet, da man entweder mit Parametern (first choice) arbeitet oder das entsprechende Quoten/Escapen durch eine DBMS Funktion erledigen sollte (was bei der Verwendung von Parametern implizit erfolgt)

[Bernhard Geyer]

Zitat:

Zitat von p80286 (Beitrag 1188337)

ÄH?
Hat er doch? ist doch MS!?

Gruß
K-H

Das ist der MS SQL-Server und damit ein richtiges DBMS und nicht Access.
Dort kenn ich nur dieses "wir machen alles anders als der SQL-Standard".