| |
|
|
- page 1 - |
|
 RGH | Getestet avec Profan2cpp 1.6b:
si chez InStr() un dritter paramètre (Offset) avec angegeben wird, wird cette offensichtlich um 1 faux interpretiert. Folgendes Testprogramm pouvoir es deutlich:
declare split%, pos%, phrase$, text$
text$ = Hugo quoi here. Hugo quoi here.
imprimer instr(Hugo, text$) dans XProfan et Prf2Cpp juste: 1 - 1
imprimer instr(Hugo, text$,1) dans XProfan et Prf2Cpp juste: 1 - 1
imprimer instr(Hugo, text$,16) dans XProfan et Prf2Cpp juste: 16 - 16
imprimer instr(Hugo, text$,17) dans XProfan et Prf2Cpp UNgleich: 0 - 16
waitinput
end
dans XProfan liefert qui dernier la ligne korrekterweise la valeur 0, là ab Position 17 (cela u im 2. Hugo) qui gesuchte String Hugo oui pas plus vorkommt. Prf2Cpp liefert hingegen la valeur 16, qui définitif avant qui Stelle liegt, ab qui gesucht wird.
Salut Roland (ansonsten de Profan2CPP begeistert, là sich avec cela sans jeden Aufwand nahezu alle Programme per Knopfdruck deutlich beschleunigen laisser) |
|
|
| 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 ▲ |
|
|
|
|
| |
|
- page 1 - |
|
 RGH | Sebastian König
trop en Erscheinungstermin peux je malheureusement encore rien dire
Es eilt pas. si on es la fois rausgefunden hat peux on qui Abfrage entsprechend modifizieren. si cela Ergebnis de Instr() größer comme qui Longueur des Cordes ist, ist es plan comme 0 trop werten.
Allerdings c'est moi aujourd'hui (je beschleunige dans qui Firma justement un de mir dans XProfan geschriebenes Statistik-Programme, qui sur 23 Millionen Datensätze aus beinahe 3000 Textdateien einliest, bearbeitet et dans un MySQL-banque de données des Rechenzentrums écrit) encore un weiterer faute aufgefallen:
2006-12-18 > 2005-07-16 13:34:26 ergibt 0 (faux), quoique qui Stringvergleich 1 (véritable) ergeben devrait. si Je l' ersten String eh bien um 9 Leerzeichen sur qui gleiche Longueur des zweiten Cordes bringe, stimmt cela Ergebnis des Vergleichs.
Salut 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
Es eilt pas. si on es la fois rausgefunden hat peux on qui Abfrage entsprechend modifizieren. si cela Ergebnis de Instr() größer comme qui Longueur des Cordes ist, ist es plan comme 0 trop werten.
pas entier: c'est im Moment vielmehr so, dass (Startposition - 1) retour wird, si qui String pas trouvé wird. je ne sais pas, pourquoi et quand je cette faute incorporé habe... wahrscheinlich ist es bisher pas aufgefallen, là qui Default pour qui Startposition simple 1 ist et ensuite korrekt 1 - 1 = 0 retour wird...
RGH
Allerdings c'est moi aujourd'hui (je beschleunige dans qui Firma justement un de mir dans XProfan geschriebenes Statistik-Programme, qui sur 23 Millionen Datensätze aus beinahe 3000 Textdateien einliest, bearbeitet et dans un MySQL-banque de données des Rechenzentrums écrit) encore un weiterer faute aufgefallen:
2006-12-18 > 2005-07-16 13:34:26 ergibt 0 (faux), quoique qui Stringvergleich 1 (véritable) ergeben devrait. si Je l' ersten String eh bien um 9 Leerzeichen sur qui gleiche Longueur des zweiten Cordes bringe, stimmt cela Ergebnis des Vergleichs.
Hmm. ici habe je évident cela Verhalten des Stringsvergleich dans XProfan évident pas oui c'est ca genug analysiert... qui Code, qui chez qui >-opération letztlich aufgerufen wird, sieht im Moment so aus (aus pstring.h):
D.h. avant dem lexikographischen comparaison wird erstmal geprüft, si pas qui une déjà länger ou bien kürzer comme l'autre ist. si cela dans XProfan pas so ist, muss je cela wohl changement... je melde mich voraussichtlich demain la fois avec einer neuen Version 
MfG
Sebastian |
|
|
| |
|
|
|
 RGH | Sebastian König
avant dem lexikographischen comparaison wird erstmal geprüft, si pas qui une déjà länger ou bien kürzer comme l'autre ist. si cela dans XProfan pas so ist, muss je cela wohl changement... je melde mich voraussichtlich demain la fois avec einer neuen Version 
non, c'est dans XProfan (et Basic et Delphi ...) pas so. qui Longueur des Cordes tut rien zur l'affaire. un Leerstring ist qui Kleinstmögliche String, ansonsten zählen seulement qui Ansicodes qui marque. < chr$(0) < chr$(1) ... < ... text < text1 ... aber text > texa1
Kurz: je denke, tu dois qui Längenüberprüfung simple omettre.
Salut 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: je denke, tu dois qui Längenüberprüfung simple omettre.
oui, so fais je es maintenant - seulement pour den le cas, dass einer qui beiden Cordes vide ist, musste je encore une Zusatz-Abfrage einbauen.
une korrigierte Version allez juste per eMail à toi raus .
MfG
Sebastian |
|
|
| |
|
|
|
 RGH | Sebastian König
une korrigierte Version allez juste per eMail à toi raus  .
Super! merci!
qui beiden Probleme sommes weg. mais je suis sur un weiteres gestoßen: Embedded SQL scheint pas trop marcher. (peux es son, dass es defaultmäßig ausgeschaltet ist?)
si 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
d'autre
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
ici meldet sich qui ODBC-Treiber avec qui annonce, dass qui SQL-syntax near values (:id_db$;:time... pas dans Ordre ist. cela pourrait chez eingeschaltetem embedded SQL so nie beim ODBC-Treiber arriver.
Salut Roland
(Sorry, dass je cet Fil pour qui annonce missbrauche, mais vom Arbeitsplatz peux/darf je aucun 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! merci!
qui beiden Probleme sommes weg.
Ah, super - c'est Schonmal bien! 
RGH
mais je suis sur un weiteres gestoßen: Embedded SQL scheint pas trop marcher. (peux es son, dass es defaultmäßig ausgeschaltet ist?)
si 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
d'autre
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
ici meldet sich qui ODBC-Treiber avec qui annonce, dass qui SQL-syntax near values (:id_db$;:time... pas dans Ordre ist. cela pourrait chez eingeschaltetem embedded SQL so nie beim ODBC-Treiber arriver.
Eigentlich sollte es eingeschaltet son, si es pas explizit avec qui Kommandozeilen-Option -noemsql deaktiviert wird. je vois la fois pour, quoi là schiefläuft et melde mich wieder.
MfG
Sebastian |
|
|
| |
|
|
|
 Sebastian König | Ok, qui Ursache des Problems était droite vite trouvé: Profan2Cpp berücksichtigt embedded SQL seulement direct dans SQLExec-Befehlen! j'étais en ausgegangen, dass cela aussi dans XProfan so ist...
Ist es réellement so, dass es dans XProfan avec beliebigen Literalen funktioniert?
MfG
Sebastian
Nachtrag: je comprends aussi qui Aider so, dass es seulement chez SQLExec funktioniert:
XProfan-Aider
chez SQLExec peut ab XProfan 9 direct Variablen, comment dans embedded SQL chez C++ bzw. Java, eingesetzt volonté. simple une Doppelpunkt avant qui Variable: (...)
mon Vermutung (bzw. Befürchtung) ist, dass XProfan den String dynamisch untersucht et ggf. qui Variablennamen ersetzt. dans Profan2Cpp allez ca malheureusement konzeptionell pas - qui String muss zum la date qui Übersetzung aufgelöst volonté.... |
|
|
| |
|
|
|
 RGH | allô Sebastian,
embedded SQL fubktioniert dans qui acte seulement chez SQLExec et pas chez beliebigen Literalen.
(je hatte dans qui acte aussi avec qui Version pour beliebige Literale experimentiert, pour mais à cause de qui einfachen Hochkommas, qui une Stringwert einschließen, aucun sinnvolle Anwendung trouvé.)
Beim obigen Beispiel funktioniert cela interne alors so: Im String SQL$ steht alors toujours cela, quoi aussi im Programme steht, alors z.B. where id = :id$. seulement qui SQLExec-Befehl selbst untersucht den ihm übergebenen String sur eingebettete Variablen et ersetzt cet ensuite par ihren le contenu. Würde dans id$ alors z.B. qui Wert session5A6BC95601 stehen, serait aus :id$ ensuite alors where id = session5A6BC95601 volonté. qui Auflösung peux naturellement seulement zur Laufzeit geschehen, aussi dans qui Runtime.
Ok, je sais, dass cela qui l'affaire pour toi pas einfacher pouvoir. Möglicherweise dois Du embedded SQL réellement sur cela directe Literal derrière SQLExec beschränken. mais malheureusement funktioniert cela derzeit aussi pas. si je cela avec den obigen SQL$-Cordes fais ...
si 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
d'autre
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
... stürzt qui Prof2CPP avec einer Schutzverletzung ab. (chez kürzeren Zeilen fonctionne il mais par.)
mais s'il te plaît maintenant aucun Hektik, Sebastian. j'ai mon Programme maintenant umgeschrieben et sur embedded SQL verzichtet (là voyons qui Zeilen arrêt ensuite quelque chose komplizierter aus: ... values ( + id$ + + ...) et es scheint maintenant trop marcher. Aus dem mehrtägigen Statistikjob ist maintenant hoffentlich wieder une l'affaire geworden, qui sur nuit durchläuft. (on läßt Vorgesetzte arrêt pas volontiers longtemps attendre ... ;) )
Salut 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 ▲ |
|
|
|
| |
|
- page 2 - |
|
|
 | je crois Sebastians mögliches Problem im Bezug sur qui Herstellung selbiger Fonctionnalité hat plutôt qui Ursache cela il avec Listen travailler devrait um sur Variableninhalte zugreifen trop peut quelle qui Funktion selbst garnicht bekannt son peut. qui Source wird hierbei oui pas interpretiert et qui Variablen sommes im prf2cpp-le cas oui echte Variablen. quoi cependant un einfacher Workaround pour Sebastian son pourrait ist cela paraphraser solcher Literale par seinen Präkompiler dans qui pas-embed-variante ala +vari$+. |
|
|
| |
|
|
|
 RGH | iF
quoi cependant un einfacher Workaround pour Sebastian son pourrait ist cela paraphraser solcher Literale par seinen Präkompiler dans qui pas-embed-variante ala +vari$+.
quoi mais, si im String réellement so quelque chose comment :hugo$ stehen soll et il pas pour SQLExec gedacht ist? (Zugegeben: c'est plutôt unwahrscheinlich, mais plan pas unmöglich.)
je denke, es spricht rien dagegen, trop dire: Prf2CPP peux embedded SQL seulement, si, si es comme Literal derrière SQLExec steht. ensuite peux sich qui geneigte Programmierer dananch richten.
Salut 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
quoi mais, si im String réellement so quelque chose comment :hugo$ stehen soll et il pas pour SQLExec gedacht ist? (Zugegeben: c'est plutôt unwahrscheinlich, mais plan pas unmöglich.)
Sollte on c'est pourquoi pas vorsorglich qui Eingaben dahingehend überprüfen? je crois j'ai cela XProfansche SQLEmbedded donc encore pas entier kappiert - cela soll ici mais pas cela Thema son.
quoi je versuchte trop dire ist cela es plan dem Sebastian pas possible ist zur Laufzeit sur den le contenu einer Variablen zuzugreifen en nom aussi seulement zur Laufzeit ermittelt/erzeugt wird sans sur z.B. listen comment spezielle assoziative Arrays zugreifen trop doit. Daher mon Vorschlag des Umschreibens par den Präkompi. comment il löst wird il mais naturellement selbst am besten savons - je hab oui seulement gestochert.  |
|
|
| |
|
|
|
 Sebastian König | iF hat cela Problem oui c'est ca richtig beschrieben... c'est cela, quoi je avec qui String muss zum la date qui Übersetzung aufgelöst volonté quelque chose unpräzise ausgedrückt habe.
comme Notlösung schwebt mir im Moment avant, une Possibilité einzubauen, cela embedded SQL temporär aussi pour beliebige Literale einzuschalten, am besten avec dem gleichen Konzept sur spezielle Kommentare, comment je es aussi déjà pour Call() et Externe() im Zusammenhang avec qui Multithread-Problematik incorporé habe (siehe Punkt 3 sous Sonstige Features dans qui Profan2Cpp-Aider). cela hätte den Vorteil, dass on qui Codes avec droite geringem Aufwand gleichzeitig trop XProfan et Profan2Cpp kompatibel faire peux.
Um l'autre angesprochene Problem kümmere je mich chez Gelegenheit - peut-être. am Wochenende, là je demain zunächst encore à qui Uni et ensuite den ganzen l'après-midi im rame son werde... Zum Glück eilt es oui pas 
MfG
Sebastian |
|
|
| |
|
|