PureBoard

Ich habe endlich den Fehler in meiner Datenbank gefunden, der mich
schon die ganze Zeit beschäftigt.

Dabei macht ValQ() einen Fehler, wo Val() keinen macht. Aber schaut es
euch einfach an: Kann jemand den Fehler liebenswürdiger Weise an Fred weiterleiten, wenn er nicht schon bekannt ist?

Vielen Dank im Vorraus!

///Edit:
Bei ValF() und ValD() treten die selben Fehler auf.

Hallo,

ist es nicht eher so, dass bei Val() der Fehler liegt. Immerhin versuchst du, einen nicht initialisierten String in einen Wert zu konvertieren.

Gruß Karl

Variablen sind in PB nullinitalisiert. Wenn ich einfach so aus heiterem Himmel <Debug b> aufrufe, wird da 0 stehen. Um es bei strings ein bisschen deuticher zu machen: <Debug text$> wird aus heiterem Himmel auch "" ergeben.

<Debug Val(temp$)> wird 0 ergeben, dasselbe mit ValQ() stürzt komischerweise ab (Invalid memory access).
Definiere ich die Variable temp$ aber vorher etwa mit Define, klappt's wunderbar.

Fazit: BUG!

Na ja, ganz so ist es nicht. Er legt einen Verweis (Pointer) auf eine Speicheradresse, an der ein String abgelegt werden soll (bzw. von dort aus einen weiteren Verweis auf den Heap). Mehr nicht.

Wahrscheinlich ist dann in der Val()-Funktion eine Bedinungsabfrage enthalten - bei den anderen Versionen halt nicht.

Ist sowieso ´ne Unart, nicht initialisierte Variablen zu verwenden.


Hey AND51, füge mal das hier vor dem Debug ein und du wirst sehen:
Gruß Karl

Das Problem habe ich bei meiner Datenbank.

Wenn z.B. die erste Spalte den Typ String hat und man erstellt eine neue
Zeile ohne gleich etwas reinzuschreiben, dann wird nur Speicherplatz für die
Spalten reserviert.
Liest man jetzt aus der neuen Zeile aus Spalte 1 einen Quad aus, liest er den
noch nicht gesetzten String aus und benutzt ValQ() um ihn umzuwandeln. Und
da passiert dann das Unglück.

Ich hab halt keine Lust, dass wenn man 20 String-Spalten hat und mit einem
Mal 1000 Zeilen einfügt, ich alle 20000 Strings automatisch initialisieren
muss, damit bei einem eventuellen GetQuad()-Aufruf kein Fehler passiert.

Ich hab das Problem jetzt so umgangen, dass ich zuerst auf *s\s <> ""
überprüfe und dann erst ValQ() mache. Aber ich finde, dass es anders auch
funktionieren sollte.

Für mich also auch ein klarer Bug.

Kenne mich mit Datenbanken nicht so aus, aber ieso hängst du beim Speichern nicht ein Leerzeichen an den String an, leer oder nicht leer?

Dann würde ValQ() auch keinen Fehler machen und 0 zurückgeben. Merkst du dass der String doch nicht leer ist, benutzt du einfach <Leftstring$, Len(string$)-1)> oder RTrim()

Ist zu umständlich und es würde unnötig viel Zeit brauchen und Speicher allokiert werden, wenn man z.B. mal eben 100.000 Strings anlegt.

Ich mache es jetzt so, wie ich es die ganze Zeit mache. Das ist am schnellsten.

´Dann würde ich an deiner Stelle aber richtig optimeiren:

*s\s <> "" raus und dafür Not *s\s schreiben

Du hast doch PB 4.00, oder?

AND51 hat geschrieben:´Dann würde ich an deiner Stelle aber richtig optimeiren:

*s\s <> "" raus und dafür Not *s\s schreiben

Du hast doch PB 4.00, oder?

wenn man optimeired wirds sowieso nichts
Deine vorgeschlagene Syntaxänderung beinhaltet keinerlei Optimierung!
Wie gesagt Syntaxänderung <> Optimierung

Na und? Selbst wenn es keine echte optimierung ist, es ist einfach cooler und besser lesbar!

Ich verweise darüber hinaus noch auf diesen Thread:

Speedtests: MeinString$="" vs. Len(MeinString$)=0