In SQLite Integer-Wert schreiben?

[Volker Z.]

Hallo Sir Rufo,

Zitat:

Zitat von Sir Rufo (Beitrag 1238044)

Zitat:

Zitat von Volker Z. (Beitrag 1238042)

Hallo,

Zitat:

Zitat von Sir Rufo (Beitrag 1238039)

Zitat:

Zitat von Volker Z. (Beitrag 1238034)

Hallo,

Zitat:

Zitat von AlexII (Beitrag 1238033)

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 :gruebel::gruebel: 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 :wink: - im Grunde ist gelesenes, gehörtes, geschriebenes Wort immer stumpfer Text, erst der Compiler u. ä. gibt der Sache Sinn. :-D

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 ... :nerd:

Zitat:

Zitat von Volker Z. (Beitrag 1238045)

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

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.

Delphi-Quellcode:

123

ist für SQL ein "Integer" und

Delphi-Quellcode:

"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.

Delphi-Quellcode:

"123" || 456

ergibt den Text "123465" und

Delphi-Quellcode:

"123" + 456

ergibt 579)

[Volker Z.]

Hallo Frank,

Zitat:

Zitat von Perlsau (Beitrag 1238046)

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:

Zitat von Perlsau (Beitrag 1238046)

Zitat:

Zitat von Volker Z. (Beitrag 1238045)

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

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) :wink:

Gruß

[Perlsau]

Zitat:

Zitat von Volker Z. (Beitrag 1238094)

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 :oops:

Zitat:

Zitat von Volker Z. (Beitrag 1238045)

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:

Zitat von Volker Z. (Beitrag 1238045)

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) :wink:

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. :thumb: