Änderungen bei Hochkommas in Strings zwischen D7 und XE4?

[p80286]

Zitat:

Zitat von Codehunter (Beitrag 1261055)

...ist die Verarbeitung von doppelten bzw. mehrfachen Hochkommas

äh ja

Code:

''<>"

das ist korrekt!

Gruß
K-H

[Uwe Raabe]

D7 und XE6 bringen beide das korrekte Ergebnis.

[himitsu]

Das Einzige, wo ich derartige Probleme kenn', ist bei der Übergabe in Scriptsprachen (z.B. im FastReport) oder in der Stringbehandlung im FinalBuilder, wo es manchmal recht wirr ist, und man kaum mitbekommt wann man wo und warum die Zeichen wie oft maskieren muß, damit 10 Befehle später der richtige String raus kommt.

Ansonsten kann/darf/wird sich so ein fundamentales Verhalten nicht ändern, da sonst alte Codes nicht mehr funktionieren würden.
Man stelle sich mal vor was wohl passieren würde, wenn sich in einem SQL-String Dieses verändert, vorallem bei denen, welche nicht parametrisiert arbeiten.

[Codehunter]

Zitat:

Zitat von himitsu (Beitrag 1261062)

Man stelle sich mal vor was wohl passieren würde, wenn sich in einem SQL-String Dieses verändert, vorallem bei denen, welche nicht parametrisiert arbeiten.

Ähm ja... Genau dadurch bin ich überhaupt drauf gestoßen weil sich seit der Umstellung von D7 auf DXE4 durch wiederkehrende SELECTs und UPDATEs plötzlich in einigen VARCHAR-Feldern führende und abschließende Hochkommas fanden und sich auch noch vermehrten.

Wenn das hier das gewollte richtige Verhalten ist:

Delphi-Quellcode:

sTest:= 'Hello ''World''!'; // Ausgabe: Hello 'World'!
sTest:= 'Hello '''World'''!'; // Ausgabe: Hello ''World''!

dann muss das hier aus unserem D7-Code ursprünglich mal ein Bug gewesen und nie aufgefallen sein:

Delphi-Quellcode:

sTest:= 'Hello ''World''!'; // Ausgabe: Hello World!
sTest:= 'Hello '''World'''!'; // Ausgabe: Hello 'World'!

[himitsu]

Dann würde ich den Fehler nicht bei Delphi suchen, sondern bei der Datenbank und vorallem bei den Schnittstellenkomponenten.

Die werden dann vermutlich irgendwo einen Bug haben.


Wolltest du nicht mal den Tippfehler beheben?
Wie erwähnt, zeigt dir der CodeHighlighter, daß der zweite Zeile definitiv falsch ist, welches dir auch der Compiler gern nochmal bestätigen wird.

Aus Sicht des Codeparsers, ist das hier korrekt, wenn man es auf den "String" bezieht.

Delphi-Quellcode:

sTest:= 'Hello ''World''!'; // im String: Hello 'World'!
sTest:= 'Hello ''''World''''!'; // im String: Hello ''World''!

Wenn man jetzt nochmal einen Parser dazwischen schaltet, welcher ebenfalls wieder die Strings entsprechend parst, dann könnte das so aussehen.
(einmal ein Parser nach Delphi-Standard und einer nach C-Standard ... auf Seite der Datenbank meist das Letztere)

Delphi-Quellcode:

sTest:= 'SELECT ''Hello ''''World''''!'''; // im Query: SELECT 'Hello ''World''' => im DB-Feld: Hello 'World'!
sTest:= 'SELECT ''Hello \''World\''!'''; // im Query: SELECT 'Hello \'World\'' => im DB-Feld: Hello 'World'!

[DeddyH]

Verwendest Du keine parametrisierten SQL-Statements? Damit würde das ganze Geraffel ersatzlos entfallen.

[Uwe Raabe]

Zitat:

Zitat von DeddyH (Beitrag 1261148)

Verwendest Du keine parametrisierten SQL-Statements?

<Sarcasm>So'n neumodisches Zeugs braucht doch eh niemand!</Sarcasm>

[bcvs]

Zitat:

Zitat von DeddyH (Beitrag 1261148)

Verwendest Du keine parametrisierten SQL-Statements? Damit würde das ganze Geraffel ersatzlos entfallen.

Oder zumindest

Delphi-Quellcode:

QuotedStr

[Codehunter]

Zitat:

Zitat von DeddyH (Beitrag 1261148)

Verwendest Du keine parametrisierten SQL-Statements?

Punkt 1: Uraltes Projekt, minimale Investition in Pflege.
Punkt 2: Kann der dortige Client nicht.
Punkt 3: Das Problem war ja nicht auf SQL-Statements beschränkt sondern auf sämtliche hartcodierte Strings.

Aber das hat sich ja heute Morgen auf wundersame Weise selbst geheilt.