In SQLite Integer-Wert schreiben?

[Volker Z.]

Hallo Sir Rufo,

Zitat von Sir Rufo:

Zitat von Volker Z.:

Hallo,

Zitat von Sir Rufo:

Zitat von Volker Z.:

Hallo,

Zitat von AlexII:

Mache ich doch...((( erkennt etwa SQLite, dass das ein in str umgewandelter int ist und speichert es als int ab?

Japp, und nicht nur SQLite - auch andere auf SQL basierende RDBMS

Gruß

Und auch der Delphi-Code ist nur eine stumpfer Text, sowie Visual Basic, C, C#, .........

Stehe ich da jetzt aufm Schlauch oder war danach gefragt?

Gruß

Nein, nicht explizit gefragt, aber vom Grundsatz her vergleichbar

Ja, ne, ist klar, - wenn ich als Südländer mal Anleihen nehmen darf - im Grunde ist gelesenes, gehörtes, geschriebenes Wort immer stumpfer Text, erst der Compiler u. ä. gibt der Sache Sinn.

Gruß

[Perlsau]

Mein lieber Volker Z,

die Übergabe von Werten an externe Programme erfolgt im Grunde immer mittels eines Strings. Das ist z.B. auch so, wenn du ein Programm mit Parametern startest: Wenn dein Programm die Parameter auswertet, muß es eventuell erwartete Zahlenwerte erst umwandeln, um sie verwenden zu können. Bei SQL-Strings, die einen SQL-konformen Text zur Manipulation einer SQL-Datenbank beinhalten (sollen), ist das ganz genau so: Zeichenfolgen, die in der Datenbank als Zahlenwerte (Integer, Currency ...) erwartet werden, müssen vom SQL-Parser des DBMS (DatenBankManagementSystem) erst in die entsprechenden Zahlenwerte umgewandelt werden. Um dem DBMS zu vermitteln, ob es sich um einen Zahlenwert oder um eine Zeichenfolge (Name, Vorname ...) handelt, wird das Quoten eingesetzt: In Hochkommas eingeschlossene Zeichenfolgen werden vom SQL-Parser nicht als Zahlenfolgen interpretiert:

Code:

insert into KUNDE
(kundennr, name, vorname, strasse, plz, ort, telefongesch, telefonprivat, email)
values (99, 'Adler', 'Felix', 'Goethestrasse 4', '30453', 'Hannover', '9856023452', '10562382', '[e-mail]');

Wie du hier in der Zeile mit den Values (Werten) siehst, wird hier die Kunden-Nummer nicht als Zeichenfolge übermittelt, sondern als Zahlenwert. Alle anderen Zeichenfolgen sind keine Zahlenwerte und deshalb gequotet, also in Hochkommas eingeschlossen. Für den SQL-Parser deines DBMS ist aber das ganze Ding ein einziger String, eben ein SQL-String, der entsprechend auseinandergenommen wird, um mit den Einzelteilen hier z.B. den neuen Eintrag zu "berechnen". Um in Delphi eine String-Variable mit einem Wert zu belegen (indizieren bzw. zuweisen), muß bereits der komplette String in Hochkommas eingeschlossen werden, damit der Delphi-Compiler – der ja auch einen Parser verwendet, um die im Quelltext stehenden Worte und Zeichen interpretieren zu können, bevor er daraus Maschinencode macht – den String als solchen erkennen kann. Werden nun im String weitere Hochkommas benötigt, kann man das Problem, daß erstmal jedes Hochkomma den String beendet, auf zwei verschiedene Arten lösen:

Delphi-Quellcode:

MySQLString := '99, ''Adler'', ''Felix'', ''Goethestrasse 4'', ''30453'', ''Hannover'',' +
               '''9856023452'', ''10562382'', ''[e-mail]''';

Wie du hier leicht erkennen kannst, werden in Delphi, um innerhalb eines Strings ein Hochkomma zu platzieren, zwei hintereinander stehende Hochkommas verwendet. Statt der zahlreichen Hochkommas kannst du aber auch Befehl QuotedStr verwenden:

Delphi-Quellcode:

Const
  K = ',';
begin
  MySQLString := '99' + K +
               QuotedStr('Adler') + K +
               QuotedStr('Felix') + K +
               QuotedStr('Goethestrasse 4') + K +
               QuotedStr('30453') + K +
               QuotedStr('Hannover') + K +
               QuotedStr('9856023452') + K +
               QuotedStr('10562382') + K +
               QuotedStr('[e-mail]');
end;

Liegen die benötigten Werte bereits in Variablen vor, z.B. in Editfeldern, kannst du auch hier den Befehl QuotedStr einsetzen:

Delphi-Quellcode:

Const
  K = ',';
begin
  MySQLString := Edit_KdNr.Text + K +
            QuotedStr(Edit_Nachname.Text) + K +
            QuotedStr(Edit_Vorname.Text) + K +
            QuotedStr(Edit_Strasse.Text) + K +
            QuotedStr(Edit_PLZ.Text) + K +
            QuotedStr(Edit_Ort.Text) + K +
            QuotedStr(Edit_TelGesch.Text) + K +
            QuotedStr(Edit_TelPriv.Text) + K +
            QuotedStr(Edit_Email.Text);
end;

So, hoffentlich war das jetzt ein wenig einleuchtend ...

Zitat von Volker Z.:

Ja, ne, ist klar, - wenn ich als Südländer mal Anleihen nehmen darf - im Grunde ist gelesenes, gehörtes, geschriebenes Wort immer stumpfer Text, erst der Compiler u. ä. gibt der Sache Sinn.

Nein, denn geübte Programmierer können auch ohne Compiler erkennen, ob ein Quelltext Sinn ergibt oder nicht.

[himitsu]

Vielleicht hab es es auch nur überlesen und es wurde schon erwähnt, aber im Grunde lag hier ein Verständnisproblem vor.

123 ist für SQL ein "Integer" und "123" ist ein Text, auch wenn Beides im SQL-Text ein "String" ist.

SQL wollte praktisch den Integer, also ohne die ", aber für den SQL-Text muß deine Integervariable in einen "String" umewandelt werden, denn diesen baust du ja als Text zusammen.
Außer du nutzt parametrisierte Abfragen, wo du deine Variable an den Parameter auch als Interger übergeben könntest.


Und ja, einige SQL-Dialekte besitzen eine automatische Typumwandlung zwischen Zahlen und Texten.
Wobei diese über die Operatoren erkennen, was da zusammengesetzt werden soll.
(z.B. "123" || 456 ergibt den Text "123465" und "123" + 456 ergibt 579)

[Volker Z.]

Hallo Frank,

Zitat von Perlsau:

Mein lieber Volker Z,

die Übergabe von Werten an externe Programme erfolgt im Grunde immer mittels eines Strings. [...]

Eine schöne und ausführliche Erklärung - nur eben falscher Adressat. Mir ist die Geschichte seit vielen Jahren klar; der TE hatte da wohl ein Verständnisproblem.

Zitat von Perlsau:

Zitat von Volker Z.:

Ja, ne, ist klar, - wenn ich als Südländer mal Anleihen nehmen darf - im Grunde ist gelesenes, gehörtes, geschriebenes Wort immer stumpfer Text, erst der Compiler u. ä. gibt der Sache Sinn.

Nein, denn geübte Programmierer können auch ohne Compiler erkennen, ob ein Quelltext Sinn ergibt oder nicht.

Da kann ich nicht widersprechen. Aber dann ist da vorher der KC (Kopf-Compiler) drüber gerutscht, hat den Code übersetzt und so "Sinn" in die Sache gebracht; so sollte meine Antwort zu verstehen sein - wenn es missverständlich war, dann tut es mir leid.

BTW: Meine Erfahrung und mein KC sagt mir, dass der SQL-Parser Dein drittes Beispiel wohl mit "You have an error in your SQL syntax; check the manual [...]" anmeckern würde (da fehlen ein paar Kommas)

Gruß

[Perlsau]

Zitat von Volker Z.:

Hallo Frank, Eine schöne und ausführliche Erklärung - nur eben falscher Adressat. Mir ist die Geschichte seit vielen Jahren klar; der TE hatte da wohl ein Verständnisproblem.

An diesen war meine ausführliche & schöne Erklärung auch gerichtet, wobei ich freimütig eingestehe, dich für diesen gehalten haben. Ich hoffe, du kannst mir diese Sünde noch einmal vergeben

Zitat von Volker Z.:

Da kann ich nicht widersprechen. Aber dann ist da vorher der KC (Kopf-Compiler) drüber gerutscht, hat den Code übersetzt und so "Sinn" in die Sache gebracht; so sollte meine Antwort zu verstehen sein - wenn es missverständlich war, dann tut es mir leid.

Naja, wenn ich Compiler lese, denke ich erstmal nicht an mein Gehirn ... Natürlich sollte jeder Programmierer wissen, wie sein Compiler arbeitet, sonst könnte er keine funktionierenden Programme schreiben. Dieses Wissen ist gleichbedeutend (nicht identisch) mit der Kenntnis der Sprache Delphi.

Zitat von Volker Z.:

BTW: Meine Erfahrung und mein KC sagt mir, dass der SQL-Parser Dein drittes Beispiel wohl mit "You have an error in your SQL syntax; check the manual [...]" anmeckern würde (da fehlen ein paar Kommas)

Wo du recht hast: Ich hatte beim Kopieren bzw. Erstellen der zweiten Version das in Konstante K abgelegte Kommazeichen vergessen. Aber ich korrigier's gleich mal, damit andere, die auf meine schöne ausführliche Erläuterung stoßen, nicht unnötig irrgeführt werden.