|
SQL/DBase: Datenformat Character mit String vergleichen
Eigentlich dürfte das ja kein Problem sein, aber ich hab jetzt zig Varianten ausprobiert aber keine funkioniert bisher.
Mit der Forum-Suchfuntkion(und Google) finde ich irgendwie fast nur Beispiele um Zahlen zu vergleichen oder das Datum oder direkt einen Text, aber fast nie eine String-Variable. Also ich hab die String-Variable schon (nach Beispielen die ich gefunden habe) mit 0 - 6 Anführungszeichen versehen und mit keinen bis zu 4 Klammern umrahmt und mit einem oder 2 "+" (jew. rechts und links) und ... |
Hallo X-Dragon,
keine Panik, das ist verhältnismäßig einfach, allerdings abhängig von der Datenbank, die Du verwendest. Zudem gibt es zwei Möglichkeiten, die angezeigten Datenstätze auf das Gesuchte zu reduzieren, nämlich über SQL (dann werden nur die gesuchten Records in die Datenmenge geschoben), oder per Filter über die geöffnete Datenmenge (OnFilterRecord). Ein Beispiel wär auch gut gewesen, aber gut, mach ich eins, zunächst mal die SQL Variante. Angenommen, Du suchst in einer Adresstabelle alle Dortmunder Adressen:
Delphi-Quellcode:
QuotedStr setzt Hochkommata vor und hinter den Suchstring und ist zwingend erforderlich!
with Query1 do begin
if Open then Close; SQL.Clear; SQL.Add('SELECT * FROM Adressen WHERE ORT LIKE ' + QuotedStr('Dortmund'); Open; end; Sollen alle Datensätze gefiltert werden, deren Ort mit 'Dor' beginnt, also z.B. auch Dormagen, kann die SELECT Anweisung mit Wildcard abgeschickt werden, das Zeichen ist datenbankabhängig (% oder &):
Delphi-Quellcode:
Das Wildcard Zeichen wird in der Regel an die Usereingabe per Code angehängt und/oder vorangestellt, je nach Fragestellung. Alternativ kannst Du den SQL String auch mit Format(... %s, ...) aufbauen. Datenbanken wie z.B. Interbase/Firebird besitzen eine erweiterte SQL Syntax und kennen WHERE Klauseln wie 'WHERE Ort STARTING WITH ...'
'SELECT * FROM Adressen WHERE ORT LIKE ' + QuotedStr('Dor%')
Falls Du Code für OnFilterRecord brauchst, sach bescheid. gruß, harrybo |
Hi,
Zitat:
Gruß hansa |
AHHHHHHHHHHHHHHHHHHHHHHHHHHHHH NEEEEEIIIIINNNNNNNNNNNNNNNNNN
Ich will doch nur einen String ganz genau vergleichen, und nicht mit 'Text' sondern mit einer String-Variablen und ohne LIKE, geht das? DB-Format ist DBase. |
Ähm, wäre es möglich das man das Character-Format von DBase nicht direkt mit einer String-Variable vergleichen kann?
Also mit LIKE funktioniert es zumindest ... |
Halt, Kommando halb zurück. :mrgreen:
Code:
So siehts bei mir aus. Was ist das jetzt ? Brauche ich etwa einfache ' oder was ? Die blöden doppelten '', für eins zu kriegen. Im SQL-Klartext wäre das doch '%suchbegriff%'. Da kommt gerade eine email, das ist bestimmt harrybo. :mrgreen: Deshalb habe ich in der Konsole noch nachgeschaut. folgendes Statement wird richtig ausgeführt:
SelectSQL.Text := 'SELECT * FROM LIEF8 WHERE UPPER (NAME) LIKE UPPER (''%' + Form3.Edit1.Text + '%'') ORDER BY NR'
Code:
Au Backe, noch ne email. Hoffentlich krieg ich den Text hier noch fertig, wenn die emails von delphi-praxis sind ist seltsamerweise der Text immer weg wenn ich da rein gehe. Deshalb schau ich erst, wenn der hier weg ist. Also : die ' werden gebraucht, die Klammern () sind für das UPPER. Alles ohne Delphi getestet. LIKE scheint also ein Sonderfall zu sein. Falls harrybo das gemeint hat, dann hab ich das falsch verstanden. So, jetzt habe ich noch um einen Kasten Bier wetten, da glaubt mir jemand nicht, daß eine der emails mit dem thema hier zu tun haben, das ging ihm zu schnell. :mrgreen:
SELECT * FROM LIEF8 WHERE UPPER (NAME) LIKE UPPER ('%suchbegriff%') ORDER BY NR;
Gruß Hansa |
Zitat:
Code:
[/code]
Query1.Close;
Query1.SQL.Text := 'SELECT * FROM tabelle WHERE feldname = ' + QuotedStr (stringvariable); Query1.Open; |
@X-Dragon
Erstens: Deine Antwort ist unhöflich denen gegenüber, die sich die Mühe machen, Dir zu helfen und mögliche Folgefragen gleich mit erwähnen. Zweitens: dass es Dir um einen genauen String Vergleich geht, hast Du nicht geschrieben. Drittens: ersetze in meinem SQL Beispiel 'Dortmund' durch Deine Variable (sorry, das hatte ich Dir zugetraut). Viertens: lass das LIKE trotzdem drin. |
Hi,
Zitat:
@X-Dragon : Da habe ich Dir im Blindflug doch die Lösung für alle Varianten gegeben. Mit SQL, mit LIKE, ohne LIKE, ohne SQL, dann brauchst Du nur die UPPER Variante deiner DB zu nehmen. Also wandelst Du den DB Eintrag und deinen String in Großbuchstaben um und vergleichst sie mit =, oder Du vergleichst sie direkt, dann gibt es eben bei = bei einem unterschiedlichen b statt B als Ergebnis false zurück. Also ehrlich gesagt, mir fällt nichts mehr ein, was man da noch sonst gebrauchen könnte. Die % bei LIKE sind auch erwähnt. Was willst Du denn noch ?????????????????????????????????????????????????? ?????????????????????????????????????????????????? ??????????????????????????????????????? Gruß Hansa |
Ja ich bitte vielmals um Entschuldigung. Ich hab selber etwas der Überblick verloren, da ich an dem Problem schon den halben Tag dransitze.
Auf jeden Fall erstmal Danke für eure Hilfe. So wie ihr es geschrieben habt, sollte es normal auch funtkionieren, allerdings hab ich jetzt die Fehlermeldung "Type Mismatch ...". Ich vermute das der Character-Datentyp bei DBase nicht ganz kompatibel zum String-Format ist, allerdings weiss ich nicht wie ich das umwandeln soll. Der Eintrag in der DB ist also vom Typ Character und auf 6 Zeichen begrenzt. Mit einem auf 6-Zeichen begrenzten String funktioniert es leider nicht. [edit] Hab den Thread-Titel mal an mein Problem angepaßt |
Hi
Zitat:
Gruß Hansa |
Ähm an Source kann ich dir auch nicht viel bieten, da ich es ja genauso mit SQL auslesen will, wie du/ihr es mit vorgeschlagen habt. Das Problem ist wohl das bei einem direkten Vergleich ohne "%" anscheind der Datentyp übereinstimmen muss.
Code:
KDNR : Feld aus DBase-Datenbank/Datentyp: Character/Länge: 6
SQL.Add('WHERE KDNR = '+sstr);
sstr : Datentyp String und String[6] ausprobiert aber trotzdem kommt da der Fehler: ---------------------------------------------------------------- Project kalender.exe raised exception class EDBEngineError with Message 'Type Mismatch in expression.'. Process stopped ... ----------------------------------------------------------------- also den Rest der SQL-Anweisung hab ich alles ausgeklammert. Ich kann die Felder aber ohne Probleme mit LIKE und "%" vergleichen, aber dann bekomme ich ja kein genaues Ergebnis. |
Hi,
in der Klammer von Add muß ein string mit + zugefügt werden, sonst nichts. sstr ist offensichtlich keiner. FALLS DER FEHLER ÜBERHAUPT DAHER KOMMT. Aber mit so was magerem kommt keiner klar. Code: SQL.Add('WHERE KDNR = '+sstr); Also schreibst Du einfach in den luftleeren Raum diese Zeile, oder was? Wenn ich hier noch lese KDNR :!: Der String besteht also aus einer Zahl, oder hast Du alphanummerische vorgesehen? Bei Zahlen läßt sich das ganze locker reduzieren auf das hier:
Code:
sstr muß hierbei ein string sein. Hierbei zu beachten "tabellenname" darf natürlich nicht so da stehen. Ersetze ihn durch den großgeschriebenen Identifier Deiner Tabelle, um die es geht.
SELECT * FROM "tabellenname" WHERE KDNR =' + sstr
Was machst Du überhaupt mit dem Add ??? Ersetze das doch einfach durch SelectSQL.Text ! Gruß Hansa[/code] |
Ok, dann wirds doch etwas umfangreicher, aber ich fass das mal noch etwas zusammen.
Code:
qry := TQuery.Create(Application);
with qry do begin DatabaseName := 'wsprei'; if genau = False then begin case idx of 0 : begin SQL.Add('SELECT KDNR, N1, N2, N3, PLZ, ORT FROM Kunden.DBF'); SQL.Add('WHERE UPPER(N1) LIKE UPPER(''%' + sstr + '%'')'); SQL.Add('OR KDNR LIKE ''%' + sstr + '%'''); SQL.Add('OR UPPER(N2) LIKE UPPER(''%' + sstr + '%'')'); SQL.Add('OR UPPER(N3) LIKE UPPER(''%' + sstr + '%'')'); SQL.Add('OR UPPER(ORT) LIKE UPPER(''%' + sstr + '%'')'); end; 1 : begin SQL.Add('SELECT KENN, KDNR, FGS, TYP, KM FROM Fahrzeug.DBF'); SQL.Add('WHERE UPPER(KENN) LIKE UPPER(''%' + sstr + '%'')'); SQL.Add('OR KDNR LIKE ''%' + sstr + '%'''); SQL.Add('OR UPPER(FGS) LIKE UPPER(''%' + sstr + '%'')'); SQL.Add('OR UPPER(TYP) LIKE UPPER(''%' + sstr + '%'')'); end; end; end else begin case idx of 0 : begin SQL.Add('SELECT * FROM Kunden.DBF'); SQL.Add('WHERE KDNR = '+ sstr); // HIER ist das Problem (naja im nächsten Punkt nochmal) //SQL.Add('WHERE UPPER(N1) = UPPER(''%' + sstr + '%'')'); //SQL.Add('OR KDNR = '+sstr); //SQL.Add('OR UPPER(N2) = UPPER(' + sstr + ')'); //SQL.Add('OR UPPER(N3) = UPPER(' + sstr + ')'); //SQL.Add('OR UPPER(ORT) = UPPER(' + sstr + ')'); end; 1 : begin SQL.Add('SELECT KENN, KDNR, FGS, TYP, KM FROM Fahrzeug.DBF'); SQL.Add('WHERE UPPER(KENN) = UPPER(' + sstr + ')'); SQL.Add('OR KDNR = ' + sstr); SQL.Add('OR UPPER(FGS) = UPPER(' + sstr + ')'); SQL.Add('OR UPPER(TYP) = UPPER(' + sstr + ')'); end; end; end; Open; First; while not EOF do begin //... auslesen des Query "sstr" ist wie ich geschrieben habe definitiv ein String! Der Wert hinter dem Feld KDNR ist zwar normal eine Zahl, hat aber aber als Datenformat: Character auf 6 Stellen festegelegt, was SQL erkennen kann wie ich gelesen hab (ich Blick aber bei den vielen SQL-Standards nicht mehr durch). Also die Datenbank hab ich nicht erstellt und kann/darf auch nichts an ihr ändern, da sie noch von einem anderen Programm verwendet wird(ok eigentlich sind es 2 Datenbanken). [edit] hab den Programmcode mal eben korrigert, wie er wirkich ist |
Hi,
fügt das Add vor jedem Teilstring des SQL-Statements automatisch ein Leerzeichen ein? Anscheinend schon, sonst käme der Fehler früher. Aber das hier macht mich stutzig :
Code:
Das ist die erste Stelle im gesamten Programmteil, in der am Schluß des Teilstrings eine Variable angehängt wird, alles andere sind Konstanten. Ich könnte mir vorstellen, daß das eine Ausnahme ist. Falls dem so ist, so würde der zusammengebaute SQL-string dann so aussehen (XYZ steht für sstr):
begin
case idx of 0 : begin SQL.Add('SELECT * FROM Kunden.DBF'); SQL.Add('WHERE KDNR = '+kd); //SQL.Add('WHERE UPPER(N1) = UPPER(''%' + sstr + '%'')'); //SQL.Add('OR KDNR = '+sstr); // HIER ist das Problem (naja im nächsten Punkt nochmal)
Code:
Was soll Dein Programm jetzt aber mit XYZOR anfangen :?: Gibts so was in Deiner DB ? :shock: Das ist jetzt zwar nur eine Vermutung, aber das mit dem ADD hab ich Dir ja gesagt, mir gefällt es jedenfalls nicht so richtig. Ändere die Zeile mal so ab
... +
OR KDNR = XYZOR UPPER(N2)
Code:
und lasse den Rest wie er ist, dann mach die Kommentare wieder weg. und sag Bescheid, was ist.
sstr + ' '
Gruß Hansa P.S.: sehe gerade noch, ein ähnliches Konstrukt ist da etwas weiter oben mit "kd". Da mußt Du natürlich dasselbe machen, falls das tatsächlich der Fehler ist :!: |
Ok, das mit Add kann ich mal ausprobieren, aber ich sehe gerade da ist mir ein, zwei Fehler unterlaufen sind. Die Variable "kd" stimmt mir "sstr" überein, ich habe nur eine zusätzliche Variable dazugenommen um verschiedene Datentyp-Konvertierungen auszuprobieren. Und der Kommentar ist auch nicht ganz an der richtigen Stelle. Ich korrigier das eben mal :).
|
Hab alles genauso gemacht, wie du es vorgschlagen hast, aber es trat wieder der selbe Fehler auf. Trotzdem danke für deine Hilfe.
Da ich so nicht weiter komme, mache ich jetzt die Suche erstmal ungenau mit
Code:
und filtere dann im Query nochmal die richtige Antwort raus, falls dies auf mehrere Datensätze zutrifft(und das tut ist es da deren Kundennummer 2- bis 5-stellig sind).
SQL.Add([color=#000080]'SELECT * FROM Kunden.DBF'[/color]);
SQL.Add([color=#000080]'WHERE KDNR LIKE UPPER('[/color][color=#000080]'%'[/color] + sstr + [color=#000080]'%'[/color][color=#000080]')'[/color]); Bez. Datenbank-Datentypen umwandeln hab ich noch was interessantes gefunden, hat mir aber selbst irgendwie nicht geholfen:  http://www.priv.bus.at/graf/quell/de...anslations.htm[edit] Ich bin gerade etwas am austesten, und zwar wie ich das richtige Ergebniss (und das einzige) am besten herrausfiltern kann und bin dabei auch über die Filter-Funktion von Query gestolpert. Von meinem ersten Eindruck her, scheint es etwas schneller zu sein als mit SQL, kann das sein? Ich versuch das nochmal genauer auszutesten. |
@X-Dragon: freut mich, dass Du Dich beruhigt hast (ja, ja, dieser sich aufstauende Ärger), aber warum weigerst Du Dich beharrlich, statt "=" den Operator LIKE einzusetzen? LIKE muss nicht zwingend mit Wildcards eingesetzt werden. Ohne Wildcards wird natürlich nach genauer Übereinstimmung selektiert. Ich habe vor längerer Zeit mit DAO bzw. ADO und dBase bzw. Access gearbeitet. Ich erinnere mich noch, dass direkte String Vergleiche mit dem "=" Operator fehlschlugen und nur LIKE in Verbindung mit dem in Hochkommas eingeschlossenen Suchbegriff, also QuotedStr(vSearchStr) funktionierten. Also
Delphi-Quellcode:
gruß, harrybo
SQL.Add('SELECT * FROM Kunden.DBF');
SQL.Add('WHERE KDNR LIKE ' + QuotedStr(sstr)); |
Zitat:
Mit LIKE hab ich es zwischendurch auch probiert gehabt, aber da muss ich wohl die Hochkommas oder Klammern oder sonst irgendwas falsch geschrieben haben. Das "=" hatte ich dann wieder eingefügt, weil es mir am passendsten schien für einen genauen Vergleich, aber man lernt ja nie aus :). Dann werde ich die Query-Filter mal wieder ausbauen, so weit sie schon drin sind ... Soviel Aufwand für eine kleine, eigentlich simple Programmzeile ... :angle2: Weißt du vieleicht, oder auch jemadn anders wie die Filter funktionieren? Vom Syntax her ist ja recht ähnlich wie SQL, könnte mir gut vorstellen das dies dann im Endeffekt auch als SQL ausgeführt wird. |
Zitat:
Wenn Du einen Filter setzt werden erst alle Daten die deiner Abfrage entsprechen übertragen und danach wird gefiltert. z.b.: Eine Adressdatenbank mit 10.000 Einträgen und einem bei dem im Feld Name das Wort "Sharky" steht.
Code:
Jetzt werden von der Datenbank all 10000 Datensätze an dein Programm übertragen aber nur einer angezeigt.
Query1.Close;
Query1.SQL.Text := 'SELECT * FROM adressen' Query1.Open; Query1.Filter := 'NAME = Sharky'; Query1.Filtered := True;
Code:
Jetzt wird von der Datenbank EIN Datensatz an dein Programm übertrag.
Query1.Close;
Query1.SQL.Text := 'SELECT * FROM WHERE name = ' + QuotedStr ('Sharky'); Query1.Open; |
@X-Dragon,
na, dann bin ich ja beruhigt, dass wir's jetzt auf der zweiten Seite dieses Threads geschafft haben. Und jetzt: schau Dir doch einfach nochmal meine erste Antwort an... gruß, harrybo |
Zitat:
Danke Sharky für die Erläuterung. Dann war es ja auf jeden Fall besser wieder koplett auf SQL umzustellen, die PC's sind nämlich nicht die Leistungsstärksten auf denen das Programm laufen soll :). |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 04:30 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz