WHERE als Variable [Erledigt]

Alles zum SQL-Dialekt

Moderator: Moderatoren

Antworten
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

WHERE als Variable [Erledigt]

Beitrag von Jan »

Moin,

wenn ich eine Variable mit der Filterbedingung belege, und die dann in den SELECT einbauen will - wie mache ich das korrekt?

also z. B.

Code: Alles auswählen

cFilter := "name = 'Schulze'"
SELECT * FROM adressen WHERE [cFilter]
Jan
Zuletzt geändert von Jan am Mi, 11. Mai 2022 10:29, insgesamt 1-mal geändert.
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 851
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 192 Mal
Kontaktdaten:

Re: WHERE als Variable

Beitrag von Marcus Herz »

Äh, welche DBE?
Gruß Marcus

Erkenne, was du findest, dann weißt du, wonach du gesucht hast
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: WHERE als Variable

Beitrag von Jan »

Hallo Marcus,

FOXCDX.

Wobei das vollkommen egal ist. Denn der meckert schon beim kompilieren rum. Ich nehme an weil da der Vergleich fehlt. Die Meldung ist "Syntax error, no more tokens but needed, near <WHERE>"

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: WHERE als Variable

Beitrag von georg »

Hallo, Jan -


die SQL-Syntax ist noch nicht komplett implementiert. Wenn der Compiler das anmeckert, wäre das für mich ein Indiz. Wenn Du eine ausgeschriebene WHERE-Anweisung wie "WHERE kdnummer = 12" verwendest, akzeptiert der Compiler das?
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: WHERE als Variable

Beitrag von Jan »

Hallo Georg,

stimmt, manches will da noch nicht.

Ich hab da mal ein wenig rumgtestet. Die Originalzeile ist länger als das, was ich zuerst gepostet hatte. Weil ich das Resultat in ein Array aus DataObjects schreiben will. Das ist dann:

Code: Alles auswählen

SELECT * FROM adressen INTO object aArray
Das läuft soweit erst einmal einwandfrei, auch auf eine dbf mit FOXCDX. Das Filtern mache ich noch, indem ich vorher einen Scope setze. Da ich aber mit dem Gedanken spiele das nach und nach alles auf SQL umzuschreiben dachte ich, das ich wenn möglich da auch gleich den Scope raus werfe und statt dessen mit WHERE arbeite.

Aber große Überraschung: Das hier gibt genau den gleichen Compiler-Fehler:

Code: Alles auswählen

SELECT * FROM adressen INTO object aArray WHERE adressr = 1
Sobald ich das umschreibe auf

Code: Alles auswählen

SELECT * FROM adressen WHERE adressr = 1 INTO object aArray
Dann wird das korrekt kompiliert, und auch korrekt ausgeführt. Wobei es Sinn macht da abweichend von der SQL-Syntax im WHERE zu schreiben: adressen->adressnr = 1. Sonst wird beim kompilieren eine unbekannte Variable angemahnt. sowas verscuhe ich zu vermeiden, aber es wird wenigstens kompiliert. Andersrum nicht.

Hier machen also die Positionen der Parameter tatsächlich einen Unterschied.

Aber sobald ich da dann wieder die Variable einbauen möchte, wird das wieder nicht mehr kompiliert.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: WHERE als Variable

Beitrag von Jan »

Moin,

inzwischen hatte ich einige Diskussionen mit Andreas und Frank dazu. Und jetzt läuft es.

Erst einmal: Ein SELECT auf eine dbf funktioneirt ja einwandfrei. Nur das WHERE nicht, sobald das als Variable umgesetzt werden muß. Alaska hat das bestätigt, die Umsetzung ist aber äußerst komplex und daher absehbar nicht geplant.

Wie es geht:

Code: Alles auswählen

FUNCTION leseSaetzeInArray(cAlias, cFeld, cWert)

oStmt      := USqlStatement():new()
oStmt:createVirtualTableFromWorkArea(cAlias)
oStmt:fromChar("SELECT * FROM " + cAlias + " WHERE " + cFeld + "=::wert")
oStmt:wert := cWert
oStmt:build():query(USQL_RESULT_OBJECTS, @aData)

RETURN aData
Das ergibt ein Array aData mit DataObjects mit den passenden Sätze.

Etwas komplexer als ein simples SELECT * FROM (cAlias), aber da ich das ja nur 1x in dieser Funktion mache, ist das kein Problem.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: WHERE als Variable [Erledigt]

Beitrag von Jan »

Im Laufe der Arbeiten damit hab ich noch zwei Bugs gefunden. Die Alaska beide als PDR anerkannt hat.

1) Das beruht darauf, das ich ja noch auf dbf zugreife. Und die Programmlogik auch noch auf darauf eingestellt ist. Problem: Logische Felder und Abfragen gehen auf .T. bzw. .F.. Wenn ich aber per SELECT Daten abrufe aus der dbf, dann wird das in 0 (=.F.) und 1 (=.T.) umgeschrieben. Das klappt natürlich nicht bei Abfragen im Code auf .T. und .F. und endet in einem Laufzeitfehler.
PDR 7494

2) Ein realer Bug ist, das numerische Werte aus einem Feld im Format Nn.0 im DataObject hinterher im Format Nn.2 steht. Wenn man in der weiteren Verarbeitung darauf vertraut daß das Zahlenformat stimmt, dann gibt das Merkwürdigkeiten. Im einfachsten Fall kann das z. B. sein das ein

Code: Alles auswählen

? cAlias->vorgang + " " + Var2Char(cAlias->reihefolge) + ": "
statt dem beabsichtigten
"Angebot 2: "
ein
"Angebot 2.00: "
schreibt.
PDR 7507

Ich korrigiere das in meiner Auslesektion, dann stimmt das in der weiteren Bearbeitung:

Code: Alles auswählen

aStructure := (cAlias)->(DbStruct())
...
// Der SELECT oben schreibt logische Felder als 0 oder 1. Was der restliche Code nicht versteht. Siehe PDR 7494
FOR i := 1 TO Len(aStructure)
    IF aStructure[i][2] = "L"
       AAdd(aFelder, aStructure[i][1])
    ENDIF
NEXT

IF Len(aFelder) >= 1
   FOR i := 1 TO Len(aArray)
       FOR j := 1 TO Len(aFelder)
           IF aArray[i]:&(aFelder[j]) = 0
              aArray[i]:&(aFelder[j]) := .F.

            ELSE
              aArray[i]:&(aFelder[j]) := .T.
           ENDIF
       NEXT
   NEXT
ENDIF

// Der SELECT oben schreibt numerische Felder auf mind. 2 Dezimalstellen um. Was alten Code brechen kann bei Ausgaben. Siehe PDR 7507
aFelder := {}
FOR i := 1 TO Len(aStructure)
    IF aStructure[i][2] = "N"
       AAdd(aFelder, aStructure[i])
    ENDIF
NEXT

IF Len(aFelder) >= 1
   FOR i := 1 TO Len(aArray)
       FOR j := 1 TO Len(aFelder)
           aArray[i]:&(aFelder[j][1]) := Val(Str(aArray[i]:&(aFelder[j][1]), aFelder[j][3], aFelder[j][4]))
       NEXT
   NEXT
ENDIF
Das könnte man natürlich auch komprimieren. Aber da das zwei verschiedene PDR sind, die eventuell auch nicht gleichzeitig behoben werden, lasse ich das der Übersichtlichkeit halber so.

Aber das muß ich auch ganz klar sagen: Auch wenn die Probleme mit dem WHERE und die beiden PDR das alles verkomplizieren, ist das Arbeiten mit dem SELECT dennoch eine ungemeine Erleichterung bei vielen Arbeiten - selbst wenn ich nur mit dbf arbeiten will. Und es ist halt der erste Schritt in der Umstellung auf der Umstieg auf SQL als Datenbanksystem. Mit Code der sowohl mit dbf als auch mit SQL läuft. Das ist schon ziemlich genial, daß das so mit Xbase++ geht. Ich schreibe gerade alles von Db..-Funktionen auf SELECT um. Tierische Fleißarbeit. Aber klappt einfach. Durch das System, das ich mir da gebaut habe, habe ich auch keinerlei Probleme im Umstieg vom satzorientieren dbf auf das mengenorintierte SQL. Wobei mir SQL natürlich noch weitaus mehr zu bieten hat, wenn ich erstmal komplett umgestiegen bin.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: WHERE als Variable [Erledigt]

Beitrag von brandelh »

Jan hat geschrieben: Mo, 06. Jun 2022 18:04 Im Laufe der Arbeiten damit hab ich noch zwei Bugs gefunden. Die Alaska beide als PDR anerkannt hat.

2) Ein realer Bug ist, das numerische Werte aus einem Feld im Format Nn.0 im DataObject hinterher im Format Nn.2 steht.
Wenn man in der weiteren Verarbeitung darauf vertraut daß das Zahlenformat stimmt, dann gibt das Merkwürdigkeiten. Im einfachsten Fall kann das z. B. sein das ein
Bei Xbase++ gibt es intern zwar LONG also ohne Nachkomma oder aber die mit Nachkommastellen,
aber bei jeder Berechnung muss man damit rechnen, dass sich das ändert.

Ich wäre nie davon ausgegangen, dass ein DataObject Feld eine solche numerische Zahlentyp Eigenschaft aus der DBF oder dem SQL Server übernimmt.

Umso besser wenn Alaska das als PDR tatsächlich einbauen will.
Gruß
Hubert
Antworten