Formate in SQL ändern

[Klaus D.]

Hallo
Ich habe folgenden SQL String.

SQL-Code:

SELECT DA.id_daten
     , DA.titel
     , DA.filmlaenge
     , DA.isbn
     , DA.erstellt
     , DA.geaendert
     , DA.sid_Genre
     , DA.sid_Format
     , DA.sid_verliehen
     , DA.verliehen_Vorname
     , DA.verliehen_Name
     , DA.verliehen_PLZ
     , DA.verliehen_Ort
     , DA.verliehen_Tel
     , DA.verliehen_am
     , FA.id_format
     , FA.format
     , GR.id_genre
     , GR.genre
     , WG.name
     , WG.id_verliehen

FROM             tbl_daten DA

LEFT OUTER JOIN  tbl_format  FA
ON              (DA.sid_format=FA.id_Format)

LEFT OUTER JOIN  tbl_genre  GR
ON              (DA.sid_genre=GR.id_Genre)

LEFT OUTER JOIN  tbl_weg  WG
ON              (DA.sid_verliehen=WG.id_verliehen)




WHERE ((UPPER(DA.titel)             like :p1) OR
       (UPPER(DA.filmlaenge)        like :p1) OR
       (UPPER(DA.isbn)              like :p1) OR
       (UPPER(DA.verliehen_Vorname) like :p1) OR
       (UPPER(DA.verliehen_am)      like :p1) OR
       (UPPER(FA.format)            like :p1) OR
       (UPPER(GR.Genre)             like :p1))

order by DA.Titel ASC

Mein Problem ist, das "DA.verliehen am" als Date gespeichert ist.der Rest sind alles Stringfelder.
wie kann ich in meinem SQL-Sring dieses Feld in meine Suchfunktion einbeziehen?
MfG...Klaus

[marabu]

Hallo Klaus,

du musst Felder, die keine String-Felder sind, per CAST() in einen String umwandeln bevor du sie mit LIKE untersuchen kannst.

Grüße vom marabu

[Klaus D.]

Es wäre nett wenn sie mir zeigen würden wie ich es wo in meinem String einbinde.
Danke

[marabu]

Die übliche Syntax ist:

SQL-Code:

SELECT CAST(Da.verliehen_am AS VARCHAR(10)) AS verliehen_am FROM ...

In diesem Forum duzen sich alle...

Freundliche Grüße vom marabu

[Klaus D.]

Mein ADS scheint mit CAST ein Problem zu haben.
folgende Fehlermeldung:
Fehlermeldung
Danke für dein Bemühen.
Mfg...Klaus

[marabu]

Das sieht mir eher nach einem groben Syntaxfehler aus. Vielleicht hätte ich dir genauer schreiben sollen, wie du es angehen musst. Ersetze diese Zeile:

SQL-Code:

 (UPPER(DA.verliehen_am)      like :p1) OR

durch hier diese Zeile:

SQL-Code:

 (CAST(DA.verliehen_am AS VARCHAR(10)) like :p1) OR

Dann sollte es funktionieren.

marabu

edit: 1 und lowercase(L) in :p1 verwechselt...

[Klaus D.]

Das selbe in Grün.
Ich werde Morgen ein wenig meine Bücher durchkämpfen und mich bei Gelegenheit noch mal melden.
Danke Klaus

[Klaus D.]

Hallo
So ich noch mal...ich komme nicht weiter.
Es scheint was mit der Formatierung des Strings zu tun zu haben.
HILFE !!!!!!
MfG...Klaus

[alzaimar]

Ich kenne ADS nicht, aber vergleicht man daten nicht mit 'BETWEEN'?
Ich mache es immer so:

SQL-Code:

Select * from MyTable Where MyDateTimeColumn Between :Date and :DateNextDay

Von Delphi aus:

Delphi-Quellcode:

...
  MyQuery.Params.ParamValues['Date'] := MyDate;
  MyQuery.Params.ParamValues['DateNextDay'] := MyDate+3599/3600; // also nicht ganz + 1 Tag, sondern +23:59 
...

'Between' hat den Vorteil, das ein eventueller Index voll zur Geltung kommt. Nur die besten Optimierer erkennen bei einem Cast auf ein VarChar und eine Filterung per 'LIKE', das ein Index verwendet werden kann. Between dagegen ist hier optimal.

[marabu]

Zitat:

Zitat von Klaus D.

Es scheint was mit der Formatierung des Strings zu tun zu haben.

Welche Formatierung von welchem String?

marabu

[Klaus D.]

Ist das keine Formatierung die ich vornehme um aus Date ein StringField zu bekommen.?
Klaus

[marabu]

Typwandlung trifft es eher - aber was genau ist die Fehlermeldung? Um den Fehler einzugrenzen solltest du es mit einem Minimal-Statement versuchen, so wie ich eines in Beitrag #4 angegeben habe.

marabu

[Union]

Hallo,

Du darfst keine expliziten Typen angeben bei der Umwandlung. ADS hat für die CAST-Datentypen Konstanten. Der Kropfstorch ;) hat sich wohl an der Syntax von MSSQL oder IB orientiert.
Es muss heissen:

SQL-Code:

CAST(DA.verliehen_am AS SQL_CHAR)

Ein so umgewandeltes Datum hat immer das interne Format 'yyyy-mm-dd'.

Zitat:

Zitat von ADS-Helpfile

The data-type parameter can be SQL_BINARY, SQL_CHAR, SQL_NUMERIC, SQL_DOUBLE, SQL_INTEGER, SQL_TIMESTAMP, SQL_TIME, or SQL_MONEY.

[marabu]

Zitat:

Zitat von Union

Der Kropfstorch hat sich wohl an der Syntax von MSSQL oder IB orientiert.

Eigentlich mehr am ANSI Standard - nur gut dass du das aufklären konntest.

Kropfstorch - tss tss

[Union]

Zitat:

Zitat von marabu

[Kropfstorch - tss tss

Na ja, wenn Du so einen Namen wählst... :stupid: Jetzt geht es aber nicht um die Einhaltung von Standards, sondern um einen speziellen Dialekt. Und ADS kennt eben leider nur die Konvertierung nach solchen Konstanten (wobei bis vorletzter Version auch CAST noch CONVERT hiess).

[Klaus D.]

Hallo
Ich bin warsch. zu BLÖÖÖD....bekomme es nicht hin
der obere Teil des SQL-Strings ist unverändert das Cast Statement habe ich wie folgt eingefügt.

SQL-Code:

    
WHERE ((UPPER(DA.titel)                   like :p1) OR
       (UPPER(DA.filmlaenge)              like :p1) OR
       (UPPER(DA.isbn)                    like :p1) OR
       (UPPER(DA.verliehen_Vorname)       like :p1) OR
       (UPPER(WG.name)                    like :p1) OR
       (CAST(DA.verliehen_am AS SQL_CHAR) like :pl) OR
       (UPPER(FA.format)                  like :p1) OR
       (UPPER(GR.Genre)                   like :p1))

order by DA.Titel ASC

sprich selbe Fehlermeldung
Danke Klaus

[Union]

Hallo Klaus,

wenn ich mir Deine ADS-Fehlermeldung nochmal anschaue, dann scheint das nichts mit dem CAST zu tun zu haben: Fehler in Zeile 15, Spalte 12, Offset 326: Genau da liegt der Fehler.

Normalerweise kommt dieser Fehler, wenn man ein Komma vergessen hat in der Select-Liste. In Deinem ersten Post sieht aber alles in Ordnung aus. Vielleicht hast Du ja ein Feld inzwischen hinzugefügt und das Komma vergessen ? Schau Dir doch mal ganz genau das Statement sowie die Fehlermeldung an. ADS macht ja immer sehr genaue Angaben, wo der Fehler steckt.

OhHo, jetzt habe ich nicht genau geschaut: Du verwendest ADS 6. Wie vorher bereist erwähnt, hieß damals CONVERT noch CAST:

SQL-Code:

(CAST(DA.verliehen_am, SQL_CHAR) like :pl)

Gibt es einen besonderen Grund, warum Du noch die 6er einsetzt? Der Support dafür wird Ende des Jahres nämlich endgültig eingestellt. Local Version (max 5 User) ist weiterhin kostenlos.

[Klaus D.]

wenn ich mir das neuere ADS lade wie sieht das mit meinen bis dahin erstellten Datenbanken aus?
Du meinst ich sollte mein ADS updaten?
Danke und Tschö Klaus

[Klaus D.]

Ich noch mal
Das Update auf 8.0 hat was gebracht...kein Fehler ! aber leider auch kein Ergebnis
bei der Eingabe eines Datum :-(

SQL-Code:

SELECT DA.id_daten
     , DA.titel
     , DA.filmlaenge
     , DA.isbn
     , DA.erstellt
     , DA.geaendert
     , DA.sid_Genre
     , DA.sid_Format
     , DA.sid_verliehen
     , DA.verliehen_Vorname
     , DA.verliehen_Name
     , DA.verliehen_PLZ
     , DA.verliehen_Ort
     , DA.verliehen_Tel
     , Da.verliehen_am
    
     , FA.id_format
     , FA.format
     , GR.id_genre
     , GR.genre
     , WG.name
     , WG.id_verliehen

FROM             tbl_daten DA

LEFT OUTER JOIN  tbl_format  FA
ON              (DA.sid_format=FA.id_Format)

LEFT OUTER JOIN  tbl_genre  GR
ON              (DA.sid_genre=GR.id_Genre)

LEFT OUTER JOIN  tbl_weg  WG
ON              (DA.sid_verliehen=WG.id_verliehen)




WHERE ((UPPER(DA.titel)                   like :p1) OR
       (UPPER(DA.filmlaenge)              like :p1) OR
       (UPPER(DA.isbn)                    like :p1) OR
       (UPPER(DA.verliehen_Vorname)       like :p1) OR
       (UPPER(WG.name)                    like :p1) OR
       (CAST(DA.verliehen_am AS SQL_CHAR) like :pl) OR
       (UPPER(FA.format)                  like :p1) OR
       (UPPER(GR.Genre)                   like :p1))

order by DA.Titel ASC

Edit1.OnChange.....

Delphi-Quellcode:

V_Suchstring:=SuchEdit.Text;
 DataMod.SQL.Close;
 DataMod.SQL.Params[0].AsString :=(ANSIUPPERCASE('%'+V_Suchstring+'%'));
 DataMod.SQL.Open;

MfG...Klaus

[marabu]

Hallo Klaus,

eine Datenbankabfrage im Edit.OnChange() ist nicht so geschickt - wegen der Verzögerungen bei jedem Tastendruck. Wenn du kein Ergebnis erhältst, dann kann das auch daran liegen, dass der Suchwert und die Feldinhalte nicht zueinander passen.

Grüße vom marabu

[alzaimar]

Blöde Frage:
Kann man eigentlich *noch langsamer* in einer Datenbank suchen? Ich meine, jeder halbwegs begabte Anwender sollte doch wissen, wonach er sucht (Titel, Datum etc.) Wenn man unbedingt unspezifiziert suchen will, dann sollte man mal an sowas wie Volltextindexe denken, aber wer will das?
Ich kann ja noch verstehen, das man Titel, Autor etc. gleich behandelt, aber ein Datum mit einem Titel in einen Topf zu schmeissen ist doch wirklich ... :wall:

[Klaus D.]

Hallo
Es ist ja richtig...Leider gehöre ich nicht zu den Profis :-( sprich Delphi ist mein Hobby.
Betrachtet doch einfach mein Problem als Grundsatz. Ich wollte einfach nur wissen ob und wenn wie eine solche Problemstellung zu lösen ist,wie ich es am Ende anstelle sei mal dahingestellt,außerdem werden sich niemals mehr wie 500 Datensätze in der Tebelle befinden.
Ist denn eine indizierte Suche(z.Bsp. setFilter) wesentlich schneller als mein Lösungsweg?
Ihr habt mir aber trotzden sehr geholfen...und das Spiel in diesem Forum ist ja Nehmen und Geben und so soll es ja auch bleiben.
WEIHNACHTEN wünsch ich !!

[alzaimar]

Hi Klaus,

so war das nicht gemeint... Aber es bringt viel, etwas Ordnung in die Problemstellung zu bringen, auch, oder gerade weil es ein Hobby ist. Dann macht das Hobby einfach noch mehr Spass...

Ich würde die Suche sogar komplett im Speicher durchführen und bei 5000 Datensätzen und nur einer Tabelle komplett auf eine DB verzichten. Nicht, das das einfacher wäre, aber erstens lernt man was beim Programmieren einer Suchfunktion und zweitens benötigt man keine DB o.ä.

Frohes Fest schon mal.

[Union]

Hallo Klaus,

dass er bei Deiner Datumssuche nichts findet, liegt daran, dass ADS Datumsstrings im Format 'yyyy-mm-dd' erwartet. Wenn Du den Inhalt eines Eingabefeldes an die Abfrage übergibst, wird wahrscheinlich mit 'mm.dd.yyyy' gearbeitet. Damit erhältst Du dann nie Treffer.