| |
|
|
rquindt | Hallo Ich möchte beim Befüllen einer Firebird 3.0 Datenbank ca. 40 Values trasferimento. Versuche diese als Array zu trasferimento scheitern: SQLSTR$ = "INSERT INTO KUNDEN" + " (KdName,KdVorname,KdStrasse,KdPLZ,KdOrt) \ VALUES (:Transfer$[1], :Transfer$[2], :Transfer$[3], :Transfer$[4], :Transfer$[5])"
Im Moment helfe ich mir so: SQLSTR$ = "INSERT INTO KUNDEN" + " (KdName,KdVorname,KdStrasse,KdPLZ,KdOrt) \ VALUES (:Transfer2$, :Transfer3$, :Transfer4$, :Transfer5$, :Transfer6$)"
Ich hatte auch schon versucht, die Values per Mid$(Transfer$,x,y) aus dem ursprünglichen String zu trasferimento. Hat auch nicht funktioniert
Gibt es eine Alternative? |
|
|
| |
|
|
|
H.Brill | Nimm mal die andere Variante ohne Postfix :
Statt des Postfix kommt am Ende ein Semikolon.
Ansonsten wäre das ein Wunsch an Roland, die Arrays noch mit dazu zu nehmen. Auch die Array-Funktion
potuto er berücksichtigen. |
|
|
| Benutze XPROFAN X3 + FREEPROFAN Wir sind die XProfaner. Sie werden von uns assimiliert. Widerstand ist zwecklos! Wir werden alle ihre Funktionen und Algorithmen den unseren hinzufügen.
Was die Borg können, können wir schon lange. | 22.12.2016 ▲ |
|
|
|
|
Michael W. | Es sollte eigentlich beides funktionieren, wenn man die Variable mit einem Semikolon abschließt, also H.Brill's Variante per beide Variablen-Arten. Danach das Komma nicht vergessen, da der gesamte Teil :...; ersetzt wird.
Ja und verbessern geht immer. Ich brauche auch eine sehr grande Anzahl an Datenfeldern. Derzeit schreibe ich das in un *.SQL-File und importiere. Eine interne Lösung wäre aber besser. |
|
|
| |
|
|
|
H.Brill | Was ich noch wissen wollte : Kommt denn eine Fehlermeldung beim Testen mit Arrays ?
Kommt ja drauf an, wie Roland das implementiert hat und überhaupt Arrays vorgesehen hat. Könnte ja sein, daß der Parser das Arrayelement :Transfer$[1] als einfache Variable liest. Da dort nichts drinsteht, wird es evtl. als Leerstring behandelt.
Um der Sache auf den Grund zu gehen, würde ich mal testweise irgendwelche undeklarierten Variablen nehmen und schauen, was passiert.
Übrigens beginnt ein Array ab der Stelle [0]. Wenn du dein Array ab [0] befüllt hast (evtl. durch eine Move-Funktion), schreibt der SQL-Befehl sowieso die falschen Werte in die Felder. Z.B. den KdVorname ins Feld KdName.
Man kann es naturalmente auch so belassen, muß aber die Dimension (wenn ein fixes Array) 1 höher machen und auch beim Befüllen desselben das erste Element [0] ignorieren. Nachteil ist, daß man die XProfanfunktionen, die ein Array autom. befüllen nicht nutzen kann. |
|
|
| Benutze XPROFAN X3 + FREEPROFAN Wir sind die XProfaner. Sie werden von uns assimiliert. Widerstand ist zwecklos! Wir werden alle ihre Funktionen und Algorithmen den unseren hinzufügen.
Was die Borg können, können wir schon lange. | 23.12.2016 ▲ |
|
|
|
|
RGH | Um es kurz zu machen: Es sind hier nur einfache Variablen erlaubt, also keine Arrays!
Steht auch so in der Aiuto zu SQLExec: "Arrays und Ausdrücke sind nicht erlaubt."
Saluto Roland |
|
|
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 23.12.2016 ▲ |
|
|
|
|
rquindt | Hallo H.Brill
Vielen Dank per den Tip mit der Version ohne Postfix. Damit funktioniert es mit eindimensionalen Array´s einwandfrei. Mehrdimensionale habe ich nicht getestet.
Bei meiner ursprünglichen Variante kam die Fehlermeldung: Variable nicht declariert : Transfer$ db("fbSQLExec",hdb&,SQLSTR$,1) |
|
|
| |
|
|
|
H.Brill | Das wundert mich jetzt dennoch, zumal laut Rolands Aussage nur einfache Variablen erlaubt sind.
Naja, wenn es funktioniert, um so besser.
PS: Müßtest du mal in deinem anderen Posting circa Bytevariablen + Firebird mal probieren, ob da auch Memoryvariablen im SQL-Statement gehen. |
|
|
| Benutze XPROFAN X3 + FREEPROFAN Wir sind die XProfaner. Sie werden von uns assimiliert. Widerstand ist zwecklos! Wir werden alle ihre Funktionen und Algorithmen den unseren hinzufügen.
Was die Borg können, können wir schon lange. | 23.12.2016 ▲ |
|
|
|