Inoffizielles deutsches Xbase-Forum

hi,

ich habe scheinbar mit dem "\" ein Problem beim "Import" in eine PostgreSQL Table.

2012-07-04 07:41:26 CEST WARNING: nonstandard use of escape in a string literal at character 100
2012-07-04 07:41:26 CEST HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
2012-07-04 07:41:26 CEST ERROR: syntax error at or near "Leer" at character 128
2012-07-04 07:41:26 CEST STATEMENT: INSERT INTO Testlog VALUES(105187, 'JIMMY', '04.06.12', '23:47:25', 'JIMMY LogOff nach :00:04:04', 'E:\ALASKA\XPPYIU\DATEN\', 'Leer', 'P1600NW')

Frage : wie bekomme ich den das "\" richtig in die Table ?

Hallo, Jimmy -

vielleicht mit \\?

In Phil's Klasse gibt es mindestens eine Methode, um "escape" zu regeln. Eventuell schaust Du mal in der PostgreSQL Dokumentation nach.

Gruss,

Georg

georg hat geschrieben:vielleicht mit \\?

YUP das scheint der allgemeine Hinweis zu sein.
hm ... dann muss ich wohl alle meine "Path" Angaben überprüfen ...

georg hat geschrieben:In Phil's Klasse gibt es mindestens eine Methode, um "escape" zu regeln. Eventuell schaust Du mal in der PostgreSQL Dokumentation nach.

soweit bin ich noch nicht angelangt aber der "\" könnte ja auch noch wo anders als in einer Path Angabe vorkommen.

Guten Morgen, Jimmy -

ein besonders klares Beispiel ist das einfache Anführungszeichen, '. Es wird in SQL benutzt, um Strings zu begrenzen (also nicht die grenzenlose Freiheit wie in Xbase, zwischen einfachem oder doppelten Anführungszeichen etc. zu wählen).

Der String 'Dann sagte sie 'Hallo!'' "verwirrt" den SQL-Interpreter, daher müssen im String vorkommende Anführungszeichen "escaped" werden: 'Dann sagte sie ''Hallo!'''.

Welche Zeichen ein SQL-Server escaped haben will, obliegt der Entscheidung der Entwickler, daher mein Hinweis auf die Dokumentation, bzw. Phil's Klasse, denn dort solltest Du wahrscheinlich schneller fündig werden als in der Dokumentation.

Für SQLite habe ich ein "rein" Funktion, die beim Schreiben einfache Anführungszeichen im Text durch doppelte einfache Anführungszeichen ersetzt, sowie eine "raus" Funktion, die beim Lesen die doppelten einfachen in einfache Anführungszeichen umwandelt.

Gruss,

Georg

Wenn der Text aber in einer Variablen liegt kann man sich das sparen, da dann der Interpreter damit nichts anstellt (oder ?)

Code: Alles auswählen

cPfad := 'E:\ALASKA\XPPYIU\DATEN\'
INSERT INTO Testlog VALUES(105187, 'JIMMY', '04.06.12', '23:47:25', 'JIMMY LogOff nach :00:04:04', cPfad, 'Leer', 'P1600NW')

Hubert,

Du hast in Deinem Fall im SQL-Statement keine Variable, die durch einen Wert ersetzt wird, sondern einen Syntaxfehler

Uli

Hallo, Hubert -

nach meiner Vermutung liegst Du neben der Wahrheit. Eine INSERT Anweisung wie in Deinem Beispiel wird wohl nicht funktionieren, es sei denn, Xbase verstünde jetzt SQL Befehle.

Aber selbst dann wird dieser Befehl gemäss SQL-Syntax übersetzt, und dort wird der Feld-Inhalt übergeben, mit dem \ als Sonderzeichen, und damit knallt es.

Es sei denn, dass Alaska den \ automatisch escape'd.

Gruss,

Georg

OK, dann habe ich wohl zu sehr "Xbase PreProzessor" und zu wenig SQL gedacht, kommt leider vor

Bei meinen SQLexpress Versuchen habe ich tatsächlich die Parameter als String zusammengebaut und übergeben, dort waren weder \ noch ' im Testtext enthalten ...

ABER mit Arctica muss dass dann möglich sein - hoffe ich mal

So macht man das mit SQLexpress, wobei dieses Beispiel auf eine MDB zugreift.
Ich habe den Code geändert und \ und ' eingefügt und das wird ohne zu Murren in die MDB geschrieben:

Code: Alles auswählen

   oStmt:SQLString := 'CREATE TABLE MyTable (Field1 char(20), Field2 char(20))'
   if oStmt:Execute() == SQL_XPP_ERROR
      Return
   endif
   oStmt:SQLString := 'INSERT INTO MyTable (Field1, Field2) VALUES (?,?)'
   oStmt:Prepare()
   for i := 1 to 10
      aData[1] := LTrim(Str(i)) + " \Test\'HB' "
      aData[2] := Replicate(Chr(64+i),20)
      oStmt:Execute( aData )
   next

Hallo, Hubert -

ich bin ein begeisterter Anwender von SQL-Express, allerdings setzt dies auf der ODBC-Schnittstelle auf, und die kann ich - aus unterschiedlichsten Gründen - nicht immer voraussetzen (oder gar einfordern).

Analog zu Jimmy mit der pgDBE verwende ich die direkte C/C++-Schnittstelle zu SQLite, und da liegt die Verantwortung beim Programmierer.

Im Zusammenhang mit SQLExpress habe ich die gleichen Erfahrungen gemacht wie Du, "geht" (und ich kann mich auch nicht an einen Fall erinnern, wo es Probleme gegeben hätte). Wobei ich mal im Quelltext von SQLExpress nachsehen müsste, ob Boris ein "escape" vornimmt oder nicht.

Auf jeden Fall ist aber noch der ODBC-Treiber als zusätzliche Schicht dazwischen, die bei der C/C++-Schnittstelle fehlt.

Gruss,

Georg

Wenn ich dich also richtig verstehe hat jedes System andere gesperrte Zeichen die escaped werden müssen und jeder kocht sein eigenes Süppchen ?

brandelh hat geschrieben:Wenn ich dich also richtig verstehe hat jedes System andere gesperrte Zeichen die escaped werden müssen und jeder kocht sein eigenes Süppchen ?

Hallo, Hubert -

leider ja.

Vom Standard her sollte es lediglich das einfach Anführungszeichen sein, und ich sehe keinen konkreten Grund, warum bei PostgreSQL der \ ein Problem darstellen soll. "Eigenes Süppchen" trifft's schon.

Gruss,

Georg

Hi,

wenn ein \ im String ist, verschwindet das einfach, ich habe es probiert (leider war auch die CREATE Definition mit primary key deutlich anders).
So wird aber ein \ und jeweils ein ' um # geschrieben, also '#' ... ich sollte versuchen wie es sich mit prepaircall verhält.

Code: Alles auswählen

             for p := 1 to 99
                 cParameter += ","+CRLF+"('"+ntrim(i)+"-"+ntrim(p)+"','Testzeile:"+ntrim(i+p)+" ? ''#'' \\ / ')"
             next
             oStmt:SQLString := "INSERT INTO UVCD (UZTP, UNF_NR) VALUES "+cParameter

wenn man aber die andere Methode einsetzt (die auch noch sicher ist gegen SQL injection), dann regelt das ODBC oder SQLexpress selbständig, denn bei diesem Code

Code: Alles auswählen

        oStmt:SQLString := "INSERT INTO UVCD (UZTP, UNF_NR) VALUES (?,?)"
         oStmt:Prepare()
         for i := 1 to nMaxAnzahl
             @20,10 say i picture "999,999,999,999,999,999"

             if right(ntrim(i),2)="00"
                aPara[1] :=  LTrim(Str(i))
                aPara[2] :=  "Autor Hubert Müller's"
             else
                aPara[1] :=  "Testzeile: "+ntrim(i)+" ? ''#'' \\ / "
                aPara[2] :=  "Autor Hubert Müller's"
             endif
             if oStmt:Execute(aPara) = SQL_XPP_ERROR
                ? "Fehler bei INSERT  UVCD"
                msgbox( "Fehler aufgetreten in Zeile "+str(i), "Abbruch" )
                exit
             endif
         next

wird genau der Inhalt der Variablen in die Tabelle geschrieben:

aPara[1] := "Testzeile: "+ntrim(i)+" ? ''#'' \\ / " ==> ? ''#'' \\ /
aPara[2] := "Autor Hubert Müller's" ==> Müller's

Auf was für einer Klasse basiert denn oStmt?

Uli

Hallo, Uli -

das Beispiel bezog sich auf SQLExpress von Boris Borzic. SQLExpress setzt auf der ODBC-Schnittstelle auf, d.h. es muss für den Server, mit dem Du arbeiten willsst, einen ODBC-Treiber geben.

Gruss,

Georg

georg hat geschrieben: d.h. es muss für den Server, mit dem Du arbeiten willsst, einen ODBC-Treiber geben.

Bei SQLite bin ich mir zwar nicht sicher, aber MySQL (nutze ich fast immer), PostgreSQL, MsSQL, IBM, ORACLE haben auf jeden Fall einen

Hallo, Hubert (und Mitlesende) -

es gibt von einem Programmierer einen funktionsfähigen ODBC-Treiber für SQLite. Ich habe ein paar Benchmarks gefahren, und bin zu dem Schluss gekommen, dass der direkte Zugriff schon einen Tacken schneller ist.

Gruss,

Georg

Mit SQLite und Xbase habe ich die Routinen genutzt, die bei Pablo veröffentlicht wurden,
aber viel habe ich nicht getestet. SQLite nutze ich auf dem Android Smartphone mit Basic4Android.

Hallo, Hubert -

es gibt zwei Versionen, die zweite findest sich unter

Code: Alles auswählen

www.xbwin.com/sqlite

Von der bin ich ausgegangen und habe einiges an Anpassungen vorgenommen. Das ganze läuft jetzt zu meiner Zufriedenheit, und wenn ich in den kommenden Tagen etwas Zeit finde, werde ich meine Anpassung (auch in Absprache mit Pablo) hier veröffentlichen.

Gruss,

Georg

hi,

danke erst mal für eure Kommentare. es ist also kein "kleines" Problem wie ich hoffte.

Hubert hat geschrieben:ABER mit Arctica muss dass dann möglich sein - hoffe ich mal

die pgDBE macht mit "\" im MDIDEMO keine Probleme. deshalb war ich nicht auf das Problem gefasst.

georg hat geschrieben:Es sei denn, dass Alaska den \ automatisch escape'd.

zumindest im MDIDEMO klappt es wohl schon.

Beim DbfUpSize.EXE hat man wohl nicht daran gedacht und ich hatte zunächst vermutet das es was mit APPEND und Threads zu tun hätte.
das Logfile ist das selbe wie die Anzeige ... nichts sagend ...
Ein "mehrfaches" APPEND funktioniert ja noch nicht richtig sodass ich einen "Import" damit noch nicht durchführen konnte.

das PostgreSQL ein Logfile anlegt wusste ich zu dem Zeitpunkt noch nicht. Dort entdeckte ich dann den Hinweis auf "\"

zurück zum "native" Problem

nachdem ich mit "\\" die Daten importieren konnte und es beim "edit" im SLE ja "richtig" sah passierte mit das selbe beim "save" ("UPDATE ...") wie Hubert oben erwähnte :

Code: Alles auswählen

"E:\ALASKA\XPPYIU\DATEN\" -> Save -> "E:ALASKAXPPYIUDATEN"

das bekomme ich mit der "native" Version.

ich muss also, wie georg sagte, das "\" escape'n -> ich muss jeden String "untersuchen" ?

AUGE_OHR hat geschrieben:hi,

danke erst mal für eure Kommentare. es ist also kein "kleines" Problem wie ich hoffte.

Hubert hat geschrieben:ABER mit Arctica muss dass dann möglich sein - hoffe ich mal
die pgDBE macht mit "\" im MDIDEMO keine Probleme. deshalb war ich nicht auf das Problem gefasst.

georg hat geschrieben:Es sei denn, dass Alaska den \ automatisch escape'd.
zumindest im MDIDEMO klappt es wohl schon.

Beim DbfUpSize.EXE hat man wohl nicht daran gedacht und ich hatte zunächst vermutet das es was mit APPEND und Threads zu tun hätte.
das Logfile ist das selbe wie die Anzeige ... nichts sagend ...
Ein "mehrfaches" APPEND funktioniert ja noch nicht richtig sodass ich einen "Import" damit noch nicht durchführen konnte.

das PostgreSQL ein Logfile anlegt wusste ich zu dem Zeitpunkt noch nicht. Dort entdeckte ich dann den Hinweis auf "\"

zurück zum "native" Problem

nachdem ich mit "\\" die Daten importieren konnte und es beim "edit" im SLE ja "richtig" sah passierte mit das selbe beim "save" ("UPDATE ...") wie Hubert oben erwähnte :
Code: Alles auswählen
"E:\ALASKA\XPPYIU\DATEN\" -> Save -> "E:ALASKAXPPYIUDATEN"
das bekomme ich mit der "native" Version.

ich muss also, wie georg sagte, das "\" escape'n -> ich muss jeden String "untersuchen" ?

Der PDO-Treiber für PostgreSQL (die gängige PHP-Implementierung) bietet eine Funktion namens 'quote', die genau das macht, was du hier brauchst. Diese Funktion greift auf die von PostgreSQL zur Verfügung gestellte API zurück, soweit ich weiss, leider habe ich keine Ahnung, ob/wie sie in der Alaska-Implementierung die du nutzt zugänglich ist.
Im schlimmsten Fall wirst du diese Funktion wohl von Hand nachbauen müssen.

Inoffizielles deutsches Xbase-Forum

PostgreSQL "\"

PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"

Re: PostgreSQL "\"