select mit ' läuft nicht

[Dr. Jack]

Hallo zusammen,

mein Problem ist, dass ich mit einen Select direkt in der DB auch ein richtiges Ergebnis bekomme.

select * from fam_check where DATE(verfall, + '1 year') <= CURRENT_DATE AND (DATE(p_datum, + '5 years') <= CURRENT_DATE)

übertrage ich den Select in Delphi bekomme ich kein Ergebnis

Delphi-Quellcode:

  
       main.qryproducts.FetchOptions.AutoClose := False;
       main.qryproducts.SQL.Clear;
   
// erster Versuch so: 
       main.qryproducts.SQL.Add('SELECT * ');
       main.qryproducts.SQL.Add('FROM fam_check ');
       main.qryproducts.SQL.Add('WHERE DATE(verfall, + '+ quotedstr('1 year')+  ' ) <= CURRENT_DATE' );
       main.qryproducts.SQL.Add('AND (DATE(p_datum, + ' +   quotedstr('5 years') +') <= CURRENT_DATE) '   );

// zweite Versuch mit Parametern         
       main.qryproducts.SQL.Add('SELECT * ');
       main.qryproducts.SQL.Add('FROM fam_check ')            ;
       main.qryproducts.SQL.Add('WHERE DATE(verfall, + :jahr_begin ) <= CURRENT_DATE' );
       main.qryproducts.SQL.Add('AND (DATE(p_datum,  + :jahr_end    ) <= CURRENT_DATE) '   );

       main.qryproducts.ParamByName('jahr_begin').AsString := '1 year';
       main.qryproducts.ParamByName('jahr_end').AsString := '5 years';

       main.qryproducts.SQL.SaveToFile('S:\log.txt');

       main.qryproducts.Open;

        while not main.qryproducts.Eof do
          begin
          loeschfristen_apbetro_fam_insert_lv(main.qryproducts.FieldByName('ID').AsString,          
          main.qryproducts.FieldByName('name').AsString,main.qryproducts.FieldByName('dafo_kurz').AsString);
          main.qryproducts.Next;
          end;

die Ausgabe im Logfile kann ich 1:1 in die DB kopieren und es geht. Woran ligt es? Hoffe ihr könnt mir helfen thx.

[himitsu]

Was ist am zweiten Versuch verkehrt,
bzw. warum verwendest du das nicht?


Stimmt die Syntax so überhaupt?
Ich bin mir fast sicher, dass das + in den String gehört, und nicht davor.

SQL-Code:

DATE(verfall, '+1 year')

QuotedStr ist ausschließlich für die Pascal-Syntax, also aus ' wird ''.
Du brauchst aber eine Quote/Escape-Funktion für die SQL-Syntax, welche also aus ' ein \' machen, sowie aus \ ein \\ usw.

Hier wird es damit zufällig "funktionieren", so lange keine ' oder \ im String vorkommen.

Fazit: Such in deiner DB-Komponente, bzw. in deren Units nach einer passenden Funktion.


Und ja, daß in vielen Beispielen, Tutorials usw. QuoteStr genommen wird, ist grauenhaft und es war schon immer falsch, aber immer wieder wird dieser Mist kopiert.

[Sherlock]

Wie genau lautet denn die Fehlermeldung? Es fehlt ein kleines bisschen Exceptionhandling an der Stelle, die vielleicht Wunder wirken könnte. Oder zumindest Licht ins Dunkel bringen kann ;-)

Sherlock

[Dr. Jack]

Zitat:

Zitat von Sherlock (Beitrag 1495836)

Wie genau lautet denn die Fehlermeldung? Es fehlt ein kleines bisschen Exceptionhandling an der Stelle, die vielleicht Wunder wirken könnte. Oder zumindest Licht ins Dunkel bringen kann ;-)

Sherlock

Es gibt tatsächlich keine Fehlermeldung, ich bekomme nur einfach keinen Daten. D.h., wenn ich nur select * from fam_check nehme geht alles. Es liegt offensichtlich an der where bedingung, genauer an den Hochkommata

[Dr. Jack]

Zitat:

Zitat von himitsu (Beitrag 1495835)

Was ist am zweiten Versuch verkehrt,
bzw. warum verwendest du das nicht?



QuotedStr ist ausschließlich für die Pascal-Syntax, also aus ' wird ''.
Du brauchst aber eine Quote/Escape-Funktion für SQL, Strings, welche also aus ' ein \' machen, sowie aus \ ein \\ usw.

Fazit: Such in deiner DB-Komponente, bzw. in deren Units nach einer passenden Funktion.


Und ja, daß in vielen Tutorials QuoteStr genommen wird ist grauenhaft und es war schon immer falsch, aber immer wieder wird dieser Mist kopiert.

Der zweite Versuch liefert auch kein Ergebnis. select * from fam_check geht. Nur die Where-Bedingung scheint irgendwie fehlerhaft zu sein.

Habe mal Bilder angehängt. 01 liefert kein Ergebnis mit der vollen Query. 02 ist auf select * from fam_check reduziert

[himitsu]

Siehe mein "Edit" da oben ... das bezüglich dem "+" :angle:

[Dr. Jack]

Zitat:

Zitat von himitsu (Beitrag 1495839)

Siehe mein "Edit" da oben ... das bezüglich dem "+" :angle:

Zitat:

Zitat von himitsu (Beitrag 1495835)

Was ist am zweiten Versuch verkehrt,
bzw. warum verwendest du das nicht?


Stimmt die Syntax so überhaupt?
Ich bin mir fast sicher, dass das + in den String gehört, und nicht davor.

SQL-Code:

DATE(verfall, '+1 year')

Geht beides, sehr lustig :lol: Aber Delphi ists immer noch egal... mist Hoffnungsschimmer....

[Delphi.Narium]

Korrekte Syntax siehe: SQLite date Function

[Dr. Jack]

Zitat:

Zitat von Delphi.Narium (Beitrag 1495842)

Korrekte Syntax siehe: SQLite date Function

Daher habe ich das tatsächlich auch:): SELECT DATE('2018-11-01','+1 year'); Ich habe es geändert, aber liefert immer noch kein Ergebnis.:(

[Sherlock]

Der Unterschied ist aber immer noch da, oder hast Du den behoben?

SQL: SELECT DATE('2018-11-01','+1 year');
Delphi: SELECT DATE('2018-11-01', + '1 year');

Sherlock

[Uwe Raabe]

Nur ein Hinweis - häufig bekommt man eine aussagekräftigere Information über den tatsächlichen SQL-Text, wenn man das Text-Property der Query auswertet:
FireDAC.Comp.Client.TFDCustomQuery.Text

Für exaktere Aussagen kann man auch das FireDAC Monitoring aktivieren:

[Dr. Jack]

Zitat:

Zitat von Sherlock (Beitrag 1495845)

Der Unterschied ist aber immer noch da, oder hast Du den behoben?

SQL: SELECT DATE('2018-11-01','+1 year');
Delphi: SELECT DATE('2018-11-01', + '1 year');

Sherlock

Richtig, das + ist in den String gewandert
select * from fam_check where (DATE(verfall, '+1 year') <= CURRENT_DATE) AND (DATE(p_datum, '+5 years') <= CURRENT_DATE)
ABer das Ergebnis wird nur im DB-Browser korrekt angezeigt. Delphi findet nichts, wenn man das mal in einer Query-Abfrage testet (und zur Laufzeit kommt natürlich auch kein Ergebnis).

[Delphi.Narium]

Und wie sieht jetzt konkret Dein Quelltext aus?

[blawen]

Zitat:

Zitat von Dr. Jack (Beitrag 1495847)

Delphi: SELECT DATE('2018-11-01', + '1 year');

Müsstest Du nicht die " Hochkommata verwenden?

Delphi-Quellcode:

  'SELECT DATE("2018-11-01", "+ 1 year");

[Dr. Jack]

Zitat:

Zitat von blawen (Beitrag 1495849)

Zitat:

Zitat von Dr. Jack (Beitrag 1495847)

Delphi: SELECT DATE('2018-11-01', + '1 year');

Müsstest Du nicht die " Hochkommata verwenden?

Delphi-Quellcode:

  'SELECT DATE("2018-11-01", "+ 1 year");

es geht konket um diese Zeile:
SELECT * FROM fam_check WHERE DATE(verfall, '+1 year') <= CURRENT_DATE AND DATE(p_datum, '+5 years') <= CURRENT_DATE
Ich habe dein Vorschlag mit den Hochkommata getestet. Es geht auch hier beides. Sowohl auf DB Ebene als auch übers Query in Delphi.
Also könnte es daran m.M.n. nicht liegen.

[Dr. Jack]

Zitat:

Zitat von Uwe Raabe (Beitrag 1495846)

Nur ein Hinweis - häufig bekommt man eine aussagekräftigere Information über den tatsächlichen SQL-Text, wenn man das Text-Property der Query auswertet:
FireDAC.Comp.Client.TFDCustomQuery.Text

Für exaktere Aussagen kann man auch das FireDAC Monitoring aktivieren:

Der Hinweis ist sehr gut- danke dafür! Im Prinzip ist der Select wie im Logfile gleich.

[ol1uw]

mein Vorschlag

Delphi-Quellcode:

       main.qryproducts.SQL.Add('SELECT * ');
       main.qryproducts.SQL.Add('FROM fam_check ');
       main.qryproducts.SQL.Add('WHERE DATE(verfall,''+ 1 year'') <= CURRENT_DATE');
       main.qryproducts.SQL.Add('AND (DATE(p_datum,''+ 5 year'') <= CURRENT_DATE)');

nicht 1 doppeltes Hochkomma " sondern 2 einzelne '

[Dr. Jack]

Also das Problem ist tatsächlich gelöst. Es lag an Delphi.

Die DB-Engine versteht das und liefert ein Ergebnis: select * from fam_check where DATE(verfall, + '1 year') <= CURRENT_DATE AND (DATE(p_datum, + '5 years') <= CURRENT_DATE)
Delphi verteht das nicht und braucht den Select etwas vorgewärmt.

Delphi-Quellcode:

 
  // Datum erstmnal selbst berechnen weils delphi nicht hinbekommt
       jahr_begin := datetostr(now- 365) ;  //1 Jahr
       jahr_end := datetostr(now-1825);     //5 Jahre
 
 //     
       main.qryproducts.SQL.Add('SELECT * ');
       main.qryproducts.SQL.Add('FROM fam_check ')            ;
       main.qryproducts.SQL.Add('WHERE verfall <= '+ quotedstr(jahr_begin) );    // ohne quotedstr gehts nicht
       main.qryproducts.SQL.Add(' AND p_datum <= '+ quotedstr(jahr_end)     );

Vielen lieben Dank für eure Hilfe!

[himitsu]

Eigentlich sollte es egal sein, ob mit oder ohne Zeilenumbruch.
Das Statement wird ja eigentlich auch erst in der DB und nicht in Delphi verarbeitet.

Zitat:

ohne quotedstr gehts nicht

Natürlich nicht ... obwohl, eigentlich doch.

Delphi-Quellcode:

main.qryproducts.SQL.Add('WHERE verfall <= ''' + jahr_begin + '''');
main.qryproducts.SQL.Add(' AND p_datum <= ''' + jahr_end + '''');

Aber nochmal ... QuoteStr ist falsch.

Du kannst Milch auch in einer Papiertüte transportieren, aber sehr lange wird es nicht gut gehen, auch wenn es erstmal funktionieren mag.

QuoteStr ist für Pascal ... nicht für SQL.
Das ' ist hier zwar zufällig das Gleiche, jedenfalls zu Beginn und am Ende des Strings, aber innerhalb eines Strings ist das nicht kompatibel, was QuoteStr hier produziert, und somit falsch,
vorallem wenn es um andere Zeichen geht, speziell ' oder \


Insgesamt ist es hier eben immer besser mit Parametern zu arbeiten, da die DB-Komponente bzw. Datenbankengine das dann intern behandelt und du dich um Nichts kümmern musst.


Tipp: bei uns waren Kunden mal auf die geile Idee gekommen, in Artikelbezeichnern ein ' zu verwenden, was an einigen Stellen dann knallte, vor allem dort, wo die Übergabestellen zwischen Delphi, Python und SQL stattfanden, da die alle ihre eigene Syntax nutzen.

[BigAl]

Zitat:

Zitat von himitsu (Beitrag 1495878)

Tipp: bei uns waren Kunden mal auf die geile Idee gekommen, in Artikelbezeichnern ein ' zu verwenden, was an einigen Stellen dann knallte, vor allem dort, wo die Übergabestellen zwischen Delphi, Python und SQL stattfanden, da die alle ihre eigene Syntax nutzen.

Ich verwende eigentlich immer QuotedStr (MS SQL). Der arbeitet bei mir seit Jahren immer richtig. Wenn ein ' im string ist wird der gedoppelt. Das interpretiert der SQL-Server auch richtig. Also aus

Delphi-Quellcode:

S := 'That''s it' (wird als "That's it" im String gespeichert)
S := QuotedStr(S) ist dann "'That''s it'" im String)

Die doppelten Hochkommas (") sind natürlich oben nur um den String abzugrenzen...

Was also ist am QuotedStr bitte falsch? Wo läuft's schief? Was wäre die Alternative (außer das als S := '''That''s it''' zu schreiben - was ich nebenbei furchtbar finde).

Mit Escape-Zeichen kann der SQL-Server ja nicht wirklich was anfangen, oder? Lasse mich gerne belehren...

Alex

[himitsu]

Es ist genau andersrum.
Pascal hat mit Escapezeichen nix am Hut, aber SQL schon. (so wie praktisch jede andere C-artige Syntax)

OK, ein Doppelquote ala '' wird im SQL zwar oft auch als ' interpretiert, aber eigentlich quotet man dort mit \.

Und nun noch viel Spaß mit

Delphi-Quellcode:

QuoteStr('das ist ein Test mit \')

.
Bei

Delphi-Quellcode:

QuoteStr('ein \n ist nett')

knallt es zwar nicht, aber das N wird womöglich nicht mehr das sein, was es war,
und bei

Delphi-Quellcode:

QuoteStr('... \\ ...')

verschwindet einfach so das erste \.


Echt mal, was ist daran so schwer, die "richtige" Escape-Funktion zu verwenden, welche es irgendwo in deiner DB-Komponente geben sollte
anstatt irgendwelchem Schrott, der herfür nicht gedacht ist und auch niemals dafür gedacht war, weil er für was Anderes vorgesehen ist?

irgendwas wie EscapeLiteral (mit ' für Strings) und EscapeName (mit " für Bezeichner) oder irgendwie so


Klar, man kann auch mit dem Trabbi Ford Tourer-Nachbau von Sudhakar Yadav auf den Nürburgring .. es funktioniert, aber man nimmt etwas, was eher dafür gedacht ist.

[BigAl]

Nochmal: MS SQL kann von Haus aus mit Escape-Zeichen nichts anfangen. Zeichen wie \n oder \\ werden als genau diese ausgegeben. Ein String wie 'That\'s it' geht in MS SQL nicht.

Es gibt zwar eine Funktion zur Interpretation solcher Ausdrücke (STRING_ESCAPE) aber diese wurde aus anderen Gründen eingeführt.

z.B.

SELECT 'Das ist ein Test\'

ergibt

Das ist ein Test\

als Resultat. Entweder sprechen wir von verschiedenen Dingen oder bei manchen Datenbanken ist das halt problematisch. Bei Oracle ist es genau so. Kann man z.B. hier testen. Einfach mal "SELECT 'Hello\nWorld' eingeben...

[Delphi.Narium]

MS SQL kann damit problemlos umgehen. Das trifft aber nicht auf alle Datenbanksysteme zu.

Wenn man mit Delphi Datenbankprogramme schreibt, ohne sich auf die dahinterliegende Datenbank festzulegen, sollte man halt immer im Auge behalten, dass QuotedStr funktionieren kann, aber nicht muss.

Zitat:

Zitat von Access

In Access, you use the double-quote character around literal text, such as the Control Source of a text box: ="This text is in quotes." Often, you need quote marks inside quotes, e.g. when working with DLookup (). This article explains how.

Zitat:

Zitat von MySQL

MySQL QUOTE () produces a string which is a properly escaped data value in an SQL statement, out of a user supplied by the string as an argument. The function achieves this by enclosing the string with single quotes, and by preceding each single quote, backslash, ASCII NUL and control-Z with a backslash.

Zitat:

Zitat von PostGres

Basically, a single quote is used to define a token as a string; this is the context used in PostgreSQL for different purposes. When we write any text in a single quote it is treated as a reference object and the identifier is represented by using double-quoted text. For example, suppose our statement is like select ‘Welcome in PostgreSQL’;

Zitat:

Zitat von SQLite

The SQLite quote () function allows you to escape a string so that it’s suitable for inclusion in an SQL statement. Strings are surrounded by single-quotes with escapes on interior quotes. BLOBs are encoded as hexadecimal literals. Note that strings with embedded NUL characters cannot be represented as string literals in SQL.

Zitat:

Zitat von Ingres

Use single quotes to delimit embedded SQL string literals. To embed a single quote in a string literal, you must double it. Example: Quote usage in string literals. exec sql insert into comments (anecdotes) values ('single'' quote followed by double " quote'); This insert example writes the following string into the anecdotes column of the comments table: single' quote followed by double ...

Zitat:

Zitat von Oracle

Oracle Database offers the ability, in both SQL and PL/SQL, to specify our own user-defined delimiters for string literals. Here's how it works: you prefix your literal with the letter "q". Then you type a single quote, followeed by your starting delimiter for the literal. Then you type your literal string without having to double up on your single quote characters. When you have ...

Sie machen es alle ähnlich und doch alle ein bisserl anders, soviel zum Thema "Standardisierung" ;-)

Das Schöne an Parametern ist, dass man sich im Delphi-Quelltext nicht um diese Feinheiten kümmern muss. Da nimmt einem das die Datenbankschnittstelle ab.

[himitsu]

Ohhhh, OK, war davon ausgegangen Microsoft macht es da grundelegend so ähnlich wie auch fast alle Anderen, :oops:
wenn selbst so abgespecktes Zeugs ala SQLite es auch so macht.

Hab selbst bisher nur mit MySQL, Postgres, SQLite und irgendwas, wo ich mich nicht mehr dran erinnern kann (Access?) gearbeitet.


Aber mein Vorredner hat es ja schon nochmals gesagt.
Parameter sind eine feine Sache.

Und wenn man die Quote/Escape-Funktion der DB-Komponente nimmt, dann ist es auch egal, mit welchem DBMS man verbunden ist, weil sich dann der Richtige um das richtige Format kümmert.