| |
| |
|
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 ▲ |
|
| |
|
|
Sebastian
König | 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:
(...)
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.
Hola Roland,
danke para el Referencia! Yo habe el Fehler ya gefunden y mi Code korrigiert. Mit el nächsten Profano2Cpp-Versión se lo entonces korrekt trabajo.
Zu deren Erscheinungstermin kann Yo desafortunadamente todavía nichts sagen  ... Im Moment komme Yo gerade veces dazu, hier (flüchtig) mitzulesen y mich en konkrete Problemas con Profano2Cpp o. el SKControl.DLL a kümmern. Yo hoffe muy, dass Yo en el Frühjahr Tiempo finde, mich con el vielen neuen Features en XProfan 11 näher a beschäftigen. Möglicherweise se lo encima Weihnachten primero ni Versión 1.6c geben, el unos pocos Dinge enthält, welche Yo en el Sommer instalado haben (nichts Großartiges - sólo unos pocos kleine Verbesserungen y volle Vista-Kompatibilität... y natürlich el aktuellen Bugfix  )
MfG
Sebastian |
|
| |
| |
| |
|
|
Frank
Abbing | | Sebastian, dein Skype-Account es ständig offline. |
|
| |
| |
| |
|
|
Sebastian
König | Frank Abbing
Sebastian, dein Skype-Account es ständig offline.
Sí, stimmt - sorry... Yo meistens sólo ICQ (o. Pidgin, el normalen ICQ-Client mag Yo überhaupt no ) laufen. Usted hast natürlich bastante, Yo debería auch Skype veces otra vez starten. |
|
| |
| |
| |
|
|
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 ▲ |
|
| |
|
(457)
Deutsch
English
Français
Español
Italia