| |
| |
|
| - Página 1 - |
|
RGH | Getestet con Profano2cpp 1.6b:
Wenn en InStr() una dritter Parámetro (Offset) con angegeben se, se dieser offensichtlich en 1 falso interpretiert. Folgendes Testprogramm macht lo deutlich:
declarar split%, pos%, satz$, texto$
text$ = Hugo qué here. Hugo qué here.
imprimir instr(Hugo, texto$) In XProfan y Prf2Cpp igual: 1 - 1
imprimir instr(Hugo, texto$,1) In XProfan y Prf2Cpp igual: 1 - 1
imprimir instr(Hugo, texto$,16) In XProfan y Prf2Cpp igual: 16 - 16
imprimir instr(Hugo, texto$,17) In XProfan y Prf2Cpp UNgleich: 0 - 16
waitinput
end
In XProfan liefert el letzte Línea korrekterweise valor 0, como de Position 17 (el u en el 2. Hugo) el gesuchte String Hugo sí no mehr vorkommt. Prf2Cpp liefert hingegen valor 16, el definitiv antes Punto liegt, de el gesucht se.
Saludo
Roland
(ansonsten de Profano2CPP begeistert, como se así sin cada Aufwand nahezu todos Programas por Knopfdruck deutlich beschleunigen dejar) |
|
| |
| 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 | 18.12.2007 ▲ |
|
| |
|
|
| |
| |
| - Página 1 - |
|
RGH | Sebastian König
Zu deren Erscheinungstermin kann Yo desafortunadamente todavía nichts sagen
Lo eilt no. Wenn uno lo veces rausgefunden ha puede ser el Abfrage entsprechend modifizieren. Si el Ergebnis de Instr() größer como el Longitud des Cuerdas es, es eben como 0 a werten.
Sin embargo, heute (Yo beschleunige en el Firma gerade una de me en XProfan geschriebenes Statistik-Programa, daß encima 23 Millionen Datensätze de beinahe 3000 Textdateien einliest, bearbeitet y una MySQL-Datenbank des Rechenzentrums schreibt) todavía una weiterer Fehler aufgefallen:
2006-12-18 > 2005-07-16 13:34:26
ergibt 0 (falso), obwohl el Stringvergleich 1 (verdadero) ergeben müßte. Wenn Yo, el ersten String nun en 9 Leerzeichen en el gleiche Longitud des zweiten Cuerdas bringe, stimmt el Ergebnis des Vergleichs.
Saludo
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 | 18.12.2007 ▲ |
|
| |
|
|
Sebastian
König | RGH
Lo eilt no. Wenn uno lo veces rausgefunden ha puede ser el Abfrage entsprechend modifizieren. Si el Ergebnis de Instr() größer como el Longitud des Cuerdas es, es eben como 0 a werten.
No bastante: Es en el Moment vielmehr así, dass (Startposition - 1) zurückgegeben se, si el String No se ha encontrado se. Yo weiß no, por qué y wann Yo esta Fehler instalado habe... wahrscheinlich es bisher no aufgefallen, como el Default para el Startposition simplemente 1 es y luego korrekt 1 - 1 = 0 zurückgegeben se...
RGH
Sin embargo, heute (Yo beschleunige en el Firma gerade una de me en XProfan geschriebenes Statistik-Programa, daß encima 23 Millionen Datensätze de beinahe 3000 Textdateien einliest, bearbeitet y una MySQL-Datenbank des Rechenzentrums schreibt) todavía una weiterer Fehler aufgefallen:
2006-12-18 > 2005-07-16 13:34:26
ergibt 0 (falso), obwohl el Stringvergleich 1 (verdadero) ergeben müßte. Wenn Yo, el ersten String nun en 9 Leerzeichen en el gleiche Longitud des zweiten Cuerdas bringe, stimmt el Ergebnis des Vergleichs.
Hmm. Hier Yo offenbar el Comportamiento des Stringsvergleich en XProfan offenbar no genau genug analysiert... el Code, el en >-Operation letztlich aufgerufen se, sieht en el Moment así de (de pstring.h):
D.h. antes el lexikographischen Vergleich se primero geprüft, si no una ya länger oder kürzer como el otro es. Si el en XProfan no así es, muss Yo el wohl ändern... Yo melde mich voraussichtlich morgen veces con uno neuen Versión 
MfG
Sebastian |
|
| |
| |
| |
|
|
RGH | Sebastian König
antes el lexikographischen Vergleich se primero geprüft, si no una ya länger oder kürzer como el otro es. Si el en XProfan no así es, muss Yo el wohl ändern... Yo melde mich voraussichtlich morgen veces con uno neuen Versión
Nein, el es en XProfan (y Basic y Delphi ...) no así. El Longitud des Cuerdas tut nichts a Sache. Ein Leerstring es el Kleinstmögliche String, ansonsten zählen sólo el Ansicodes el Signo.
< chr$(0) < chr$(1) ... < ...
texto < text1 ... aber text > texa1
Kurz: Yo denke, du mußt el Längenüberprüfung simplemente weglassen.
Saludo
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 | 18.12.2007 ▲ |
|
| |
|
|
Sebastian
König | RGH
Kurz: Yo denke, du mußt el Längenüberprüfung simplemente weglassen.
Sí, así mache Yo ahora - sólo para el Fall, dass uno el beiden Cuerdas leer es, musste Todavía una Zusatz-Abfrage einbauen.
Un korrigierte Versión va igual por eMail a Usted fuera .
MfG
Sebastian |
|
| |
| |
| |
|
|
RGH | Sebastian König
Un korrigierte Versión va igual por eMail a Usted fuera .
Super! Gracias!
El beiden Problemas son weg.
Aber Yo bin en una weiteres gestoßen: Embedded SQL scheint no a trabajo. (Kann lo ser, dass lo defaultmäßig ausgeschaltet es?)
if prav_db% = 1
sql$ = insert into prav values (:id_db$,:timestamp_db$,:datum_db$,:berater_db$,:kunde_db$,:sek_db$,:modul_db$,:aktion_db$,:online_db$,:dauer_db&,:moddauer_db&,:berdauer_db&)
sqlexec sql$, 2
más
sql$ = insert into fim values (:id_db$,:timestamp_db$,:datum_db$,:berater_db$,:kunde_db$,:sek_db$,:modul_db$,:aktion_db$,:online_db$,:dauer_db&,:moddauer_db&,:berdauer_db&)
sqlexec sql$, 2
endif
Hier meldet se el ODBC-Treiber con el Meldung, dass el SQL-syntax near values (:id_db$;:time... no Haga clic en Aceptar es. Das dürfte en eingeschaltetem embedded SQL así nie beim ODBC-Treiber ankommen.
Saludo Roland
(Sorry, dass Yo dieses Hilo para el Meldung missbrauche, aber vom Arbeitsplatz kann/darf Yo no privaten eMails verschicken.) |
|
| |
| 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 | 20.12.2007 ▲ |
|
| |
|
|
Sebastian
König | RGH
Super! Gracias!
El beiden Problemas son weg.
Ah, super - el es schonmal bien!
RGH
Aber Yo bin en una weiteres gestoßen: Embedded SQL scheint no a trabajo. (Kann lo ser, dass lo defaultmäßig ausgeschaltet es?)
if prav_db% = 1
sql$ = insert into prav values (:id_db$,:timestamp_db$,:datum_db$,:berater_db$,:kunde_db$,:sek_db$,:modul_db$,:aktion_db$,:online_db$,:dauer_db&,:moddauer_db&,:berdauer_db&)
sqlexec sql$, 2
más
sql$ = insert into fim values (:id_db$,:timestamp_db$,:datum_db$,:berater_db$,:kunde_db$,:sek_db$,:modul_db$,:aktion_db$,:online_db$,:dauer_db&,:moddauer_db&,:berdauer_db&)
sqlexec sql$, 2
endif
Hier meldet se el ODBC-Treiber con el Meldung, dass el SQL-syntax near values (:id_db$;:time... no Haga clic en Aceptar es. Das dürfte en eingeschaltetem embedded SQL así nie beim ODBC-Treiber ankommen.
Eigentlich debería lo eingeschaltet ser, si no explizit con el Kommandozeilen-Opción -noemsql deaktiviert se. Yo sehe veces después de, qué como schiefläuft y melde mich otra vez.
MfG
Sebastian |
|
| |
| |
| |
|
|
Sebastian
König | Ok, el Ursache des Problems war bastante rápidamente gefunden: Profano2Cpp berücksichtigt embedded SQL sólo direkt en SQLExec-Befehlen! Yo war su ausgegangen, dass el auch en XProfan así es...
¿Es tatsächlich así, dass lo en XProfan con beliebigen Literalen funktioniert?
MfG
Sebastian
Apéndice: Yo verstehe auch el Ayuda así, dass lo sólo en SQLExec funktioniert:
XProfan-Ayuda
En SQLExec puede de XProfan 9 direkt Variables, como en embedded SQL en C++ o. Java, eingesetzt voluntad. Einfach una Doppelpunkt antes el Variable: (...)
Mein Vermutung (o. Befürchtung) es, dass XProfan el String dynamisch untersucht y ggf. el Variablennamen ersetzt. In Profano2Cpp va dies desafortunadamente konzeptionell no - el String muss para Zeitpunkt el Übersetzung aufgelöst voluntad.... |
|
| |
| |
| |
|
|
RGH | ¡Hola Sebastian,
embedded SQL fubktioniert en el Tat sólo en SQLExec y no en beliebigen Literalen.
(Tuve en el Tat auch con el Versión para beliebige Literale experimentiert, dafür aber wegen el einfachen Hochkommas, el una Stringwert einschließen, no sinnvolle Anwendung gefunden.)
Beim obigen Ejemplo funktioniert el intern also así: Im String SQL$ es also siempre el, qué auch en el Programa es, also z.B. where id = :id$.
Erst el SQLExec-Befehl incluso untersucht el ihm übergebenen String en eingebettete Variables y ersetzt esta entonces por ihren Inhalt. Würde en id$ also z.B. el Valor session5A6BC95601 posición, sería de :id$ entonces also where id = session5A6BC95601 voluntad. El Auflösung kann natürlich sólo a Laufzeit geschehen, auch en el Runtime.
Ok, Yo weiß, dass el el Sache para Usted no einfacher macht. Möglicherweise mußt Usted embedded SQL tatsächlich el direkte Literal hinter SQLExec beschränken. Aber desafortunadamente funktioniert el actualmente auch no. Wenn Yo el con el obigen SQL$-Cuerdas mache ...
if prav_db% = 1
sqlexec insert into prav values (:id_db$,:timestamp_db$,:datum_db$,:berater_db$,:kunde_db$,:sek_db$,:modul_db$,:aktion_db$,:online_db$,:dauer_db&,:moddauer_db&,:berdauer_db&), 2
más
sqlexec insert into fim values (:id_db$,:timestamp_db$,:datum_db$,:berater_db$,:kunde_db$,:sek_db$,:modul_db$,:aktion_db$,:online_db$,:dauer_db&,:moddauer_db&,:berdauer_db&), 2
endif
Aber Por favor, ahora no Hektik, Sebastian. Yo habe mein Programa ahora umgeschrieben y en embedded SQL verzichtet (como sehen el Zeilen sólo entonces algo komplizierter de: ... values ( + id$ + + ...) y lo scheint ahora a trabajo. Aus el mehrtägigen Statistikjob es ahora hoffentlich otra vez una Sache geworden, el encima Nacht durchläuft. (Man läßt Vorgesetzte sólo no gerne largo warten ... ;) )
Saludo
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 | 20.12.2007 ▲ |
|
| |
|
| |
| |
| - Página 2 - |
|
|
 | | Yo glaube Sebastians mögliches Problema en el Bezug en el Herstellung selbiger Funktionalität ha más el Ursache el él con Listen trabajo debería en en Variableninhalte zugreifen a puede welche el Función incluso garnicht bekannt ser puede. Der Source se hierbei sí no interpretiert y el Variables son en el prf2cpp-Fall sí echte Variables. Was sin embargo una einfacher Workaround para Sebastian ser podría es el Umschreiben solcher Literale por seinen Präkompiler en el no-embed-Variante ala +vari$+. |
|
| |
| |
| |
|
|
RGH | IF
Was sin embargo una einfacher Workaround para Sebastian ser podría es el Umschreiben solcher Literale por seinen Präkompiler en el no-embed-Variante ala +vari$+.
Was aber, si en el String tatsächlich así algo como :hugo$ posición se y él no para SQLExec pensamiento es? (Zugegeben: Es más unwahrscheinlich, aber eben no unmöglich.)
Yo denke, lo spricht nichts dagegen, a sagen: Prf2CPP kann embedded SQL sólo, si, si como Literal hinter SQLExec es. Dann kann se el geneigte Programmierer dananch richten.
Saludo
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 | 20.12.2007 ▲ |
|
| |
|
|
| RGH
Was aber, si en el String tatsächlich así algo como :hugo$ posición se y él no para SQLExec pensamiento es? (Zugegeben: Es más unwahrscheinlich, aber eben no unmöglich.)
Sollte uno deshalb no vorsorglich el Eingaben dahingehend überprüfen? Yo glaube Tengo el XProfansche SQLEmbedded demnach todavía no bastante kappiert - el se hier pero no el Thema ser.
Was Yo versuchte a sagen es el lo eben el Sebastian no möglichst es a Laufzeit en el Inhalt uno Variables zuzugreifen deren Name auch sólo a Laufzeit ermittelt/producido se sin en z.B. listen como spezielle assoziative Arrays zugreifen tener. Daher mein Vorschlag des Umschreibens por el Präkompi. Como él el löst se él aber natürlich incluso al besten wissen - Yo tener sí sólo gestochert.  |
|
| |
| |
| |
|
|
Sebastian
König | IF ha el problema genau correcto beschrieben... Es el, Yo con el String muss para Zeitpunkt el Übersetzung aufgelöst voluntad algo unpräzise ausgedrückt habe.
Als Notlösung schwebt me en el Moment antes, una Möglichkeit einzubauen, el embedded SQL temporär auch para beliebige Literale einzuschalten, al besten con el gleichen Konzept encima spezielle Kommentare, Yo lo auch ya para Call() y Externo() en el Zusammenhang con el Multithread-Problematik instalado habe (siehe Punkt 3 bajo Sonstige Features en el Profano2Cpp-Ayuda). Das hätte el Vorteil, dass uno el Codes con bastante geringem Aufwand gleichzeitig a XProfan y Profano2Cpp kompatibel hacer kann.
Um el otro angesprochene Problema kümmere Yo mich en Gelegenheit - evtl. al Wochenende, como Yo morgen primero todavía a el Uni y luego el ganzen Nachmittag en el Zug ser voluntad... Zum Glück eilt lo sí no
MfG
Sebastian |
|
| |
| |
| |
|
(917)
Deutsch
English
Français
Español
Italia