Ja/Nein Feld Access vs. SQL2000
Elmar Denkmann
mir bereitet die Portierung eines "Ja/Nein" Feldes aus Access nach SQL2000
Probleme.
Der SQL-Server übernimmt das "Ja/Nein" Feld beim Import der Datenbank
automatisch als "Bit" Feld. Somit gibt es einen kleinen, aber feinen
Unterschied in der Wertezuweisung:
Access (Ja/Nein):
Ja= -1 (Minus 1)
Nein= 0
SQL2000 (Bit):
Ja= 1 (Plus 1)
Nein= 0
Mein Programmcode soll für Access und SQL gleichermaßen funktionieren. Wie
aber gestalte ich eine Abfrage nach einem "Ja/Nein" Feld?
Anfangs glaubte ich, ich könne einfach den aus Access gewohnten "TRUE bzw.
FALSE" Syntax durch die Ziffern 1 bzw. 0 ersetzen. Die "1" wurde bei meinen
ersten Versuchen auch unter Access korrekt als TRUE gewertet.
Nun stieß ich auf ein Problem:
Ein
SELECT ... WHERE feld=1
liefert das korrekte Ergebnis sowohl bei Access als auch bei SQL.
Aber ein
UPDATE ... SET ... WHERE feld=1
wird unter Access nicht mehr korrekt ausgeführt! Hier funktioniert nur die
Variante
SET ... WHERE feld= -1
Komisch... warum werden die WHERE Klauseln bei SELECT und UPDATE
unterschiedlich interpretiert?
Und wie erreiche ich auf einfachem Wege, einen einheitlichen Syntax für
beide Plattformen zu schreiben, ohne für jede Abfrage zwei verschiedene
Statements zu benutzen?
Dieter Strassner
generell: Es gibt noch mehr Unterschiede zwischen ACCESS und
SQL-Server-Syntax.
Wg. Bit-Wert:
Vorschlag 1:
Definiere Dir in SQL-Server einen eigenen Datentyp das genauso regaiert wie
das ACCES-Ja/Nein-Feld
Vorschlag 2:
Bau Dir eine kleine Funktion, die Dir den Wert je nach verbundener DB
entsprechend nach Bit oder Ja/Nein_Feld umwandelt. Dto. für Abfragen in der
WHERE-Klausel. Den DB-Typ merkst Du Dir beim DB-Open in einer
Public-Property, dann kann jede Funktion ihn sich jederzeit abholen.
Du wirst also nicht umhinkommen Fallunterscheidungen zu treffen.
In ACCESS gibt es (soweit ichd as weiß ein "IF" Construkt, das wirst Du
unter SQL-Server nicht benutzen können. Dort käme dann CAST zum Einsatz.
Vielleicht kennt ja jemand einen Link zu den Syntax-Unterschieden zwischen
MS-SQL-Server und ACCESS...
--
Viele Grüße
Dieter
Rückfragen bitte nur in die Newsgroup!
EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
Elmar Denkmann
danke für Deine schnelle Antwort.
> generell: Es gibt noch mehr Unterschiede zwischen ACCESS und
> SQL-Server-Syntax.
Ja, leider, dessen bin ich mir aber bewußt.
> Vorschlag 2:
> Bau Dir eine kleine Funktion, die Dir den Wert je nach verbundener DB
> entsprechend nach Bit oder Ja/Nein_Feld umwandelt. Dto. für Abfragen in
der
> WHERE-Klausel. Den DB-Typ merkst Du Dir beim DB-Open in einer
> Public-Property, dann kann jede Funktion ihn sich jederzeit abholen.
Genauso habe ich es - kurz nach Schreiben meines Beitrages - auch umgesetzt:
Public Function SQLbool(ByVal bolValue As Boolean) As Integer
If PRGSET_UseSQLServer Then
SQLbool = Abs(CInt(bolValue))
Else
SQLbool = CInt(bolValue)
End If
End Function
Gruß,
Elmar
Ingo Moch
> mir bereitet die Portierung eines "Ja/Nein" Feldes aus
> Access nach SQL2000 Probleme.
>
> Der SQL-Server übernimmt das "Ja/Nein" Feld beim Import
> der Datenbank automatisch als "Bit" Feld. Somit gibt es
> einen kleinen, aber feinen Unterschied in der
> Wertezuweisung:
>
> Access (Ja/Nein):
> Ja= -1 (Minus 1)
> Nein= 0
>
> SQL2000 (Bit):
> Ja= 1 (Plus 1)
> Nein= 0
Gibt es beim SQL-Server nicht TRUE/FALSE-Konstanten?
Ingo
Dieter Strassner
>> Der SQL-Server übernimmt das "Ja/Nein" Feld beim Import
>> der Datenbank automatisch als "Bit" Feld. Somit gibt es
>> einen kleinen, aber feinen Unterschied in der
>> Wertezuweisung:
> [...]
> Gibt es beim SQL-Server nicht TRUE/FALSE-Konstanten?
der Datentyp heißt "Bit", nicht Boolean oder Ja/Nein-Feld. Der SQL-Server
kennt in diesem Zusammenhang kein True/False, nur 0/1. Als besonderes
"Schmankerl" gibt er sich auch mit einer "NULL" zufrieden, sofern per
Datenfelddefinition "NULL" erlaubt wurde.
Ingo Moch
>> Gibt es beim SQL-Server nicht TRUE/FALSE-Konstanten?
> der Datentyp heißt "Bit", nicht Boolean oder Ja/Nein-Feld.
Das ist dabei nebensaechlich. Bei frueherem BASIC/VB
gab es auch keinen Datentyp Boolean. Es war trotzdem
ueblich sich True- und False-Konstanten mit dem Typ
Integer anzulegen.
Ingo
Gerrit Kuhlendahl
"Ingo Moch" <myjunkmail....@gmx.de> schrieb im Newsbeitrag
news:cn2v90.3...@hamster.mochnet.de...
> Dieter Strassner meint:
>
> >> Gibt es beim SQL-Server nicht TRUE/FALSE-Konstanten?
>
> > der Datentyp heißt "Bit", nicht Boolean oder Ja/Nein-Feld.
>
> Das ist dabei nebensaechlich. Bei frueherem BASIC/VB
In diesem Zusammenhang ist das ganz und garnicht neben-
sächlich!
> gab es auch keinen Datentyp Boolean. Es war trotzdem
> ueblich sich True- und False-Konstanten mit dem Typ
> Integer anzulegen.
Schon recht! Diese Deine Ausführungen stimmen auch für eine
JET-Datenbank, NICHT jedoch für den SQL-Server!
Dort ist der Feldtyp "BIT" auch wirklich nur ein einzelnes
Bit! So wird zwar, wenn in einer Tabelle nur ein Feld
vom Typ "BIT" definiert wurde, ein Byte zur Speicherung
bereitgestellt, jedoch werden bei weiteren Definitionen
von "BIT"-Felder zunächst die verbleibenden BITs des Bytes
zur Speicherung herangezogen. Von der "echten" Datensatz-
länge ist es als gleich, ob nur ein oder ob acht Bit-Felder
in einer Tabelle definiert werden.
Viele Grüße
Gerrit
--
-------------------------------------------------------
KUH-SOFT - Die Software von glücklichen Programmierern
Bahrenfelder Steindamm 100 - D 22761 Hamburg
eMail: kon...@kuh-soft.de
Home: http://www.kuh-soft.de
Ingo Moch
> "Ingo Moch" schrieb
>> Dieter Strassner meint:
>>> der Datentyp heißt "Bit", nicht Boolean oder
>>> Ja/Nein-Feld.
>> Das ist dabei nebensaechlich. Bei frueherem BASIC/VB
> In diesem Zusammenhang ist das ganz und garnicht
> nebensächlich!
>> gab es auch keinen Datentyp Boolean. Es war trotzdem
>> ueblich sich True- und False-Konstanten mit dem Typ
>> Integer anzulegen.
> Schon recht! Diese Deine Ausführungen stimmen auch für
> eine JET-Datenbank, NICHT jedoch für den SQL-Server!
Wir brwegen uns jetzt wohl mehr im theoretischen Bereich,
aber ich sehe keinen Grund, warum es keine Konstante
namens TRUE vom Datentyp BIT geben sollte.
> Dort ist der Feldtyp "BIT" [...]
Die technische Umsetzung spielt hier keine Rolle.
Ingo
Dieter Strassner
> Wir brwegen uns jetzt wohl mehr im theoretischen Bereich,
> aber ich sehe keinen Grund, warum es keine Konstante
> namens TRUE vom Datentyp BIT geben sollte.
>
>> Dort ist der Feldtyp "BIT" [...]
>
> Die technische Umsetzung spielt hier keine Rolle.
Statt theoretisch, ganz praktisch:
const TRUE as Integer = 1
bringt einen Syntaxfehler unter VB6,SP5.
Un Nu?
Ingo Moch
> Statt theoretisch, ganz praktisch:
>
> const TRUE as Integer = 1
>
> bringt einen Syntaxfehler unter VB6,SP5.
> Un Nu?
Wir bewegen uns aber nicht innerhalb VB.
TRUE ist halt in VB vorbelegt.
Ingo
Dieter Strassner
> Wir bewegen uns aber nicht innerhalb VB.
> TRUE ist halt in VB vorbelegt.
erklär dich bitte mal genauer.
Das z.B. unter SQL-Server ein benutzerdefinierte Datentyp "Boolean" angelegt
werden kann leuchtet mir ein.
Wie bringst Du dann deine beiden Konstanten "True" und "False" ins Rennen?
Ingo Moch
>> Wir bewegen uns aber nicht innerhalb VB.
>> TRUE ist halt in VB vorbelegt.
> erklär dich bitte mal genauer.
>
> Das z.B. unter SQL-Server ein benutzerdefinierte Datentyp
> "Boolean" angelegt werden kann leuchtet mir ein.
> Wie bringst Du dann deine beiden Konstanten "True" und
> "False" ins Rennen?
Du hast gerade herausgefunden, warum ich etwas von
theoretisch schrieb.
So nebenbei hat das nichts mit einem benutzerdefinierten
Typ zu tun. Ein Konstantenname ist (meistens) nicht vom
Datentyp abhängig.
Ingo
Gerrit Kuhlendahl
"Ingo Moch" <myjunkmail....@gmx.de> schrieb im Newsbeitrag
news:cn5lfh.3...@hamster.mochnet.de...
[schnibbel]
>
> Wir brwegen uns jetzt wohl mehr im theoretischen Bereich,
> aber ich sehe keinen Grund, warum es keine Konstante
> namens TRUE vom Datentyp BIT geben sollte.
Es ist mir rein praktisch nicht klar, wie ich in VB eine
BIT-Konstante anlegen können sollte, noch dazu mit dem
Namen "True".
Aber machen wir doch mal mit der Praxis weiter. Folgendes
SQL-Statement liefert bei mir eine Fehler, wenn ich wie
folgt auf ein BIT-Feld zugreifen würde.
"SELECT ... WHERE DasBitFeld = " & VbBoolVar
Peter Fleischer
...
> Aber machen wir doch mal mit der Praxis weiter. Folgendes
> SQL-Statement liefert bei mir eine Fehler, wenn ich wie
> folgt auf ein BIT-Feld zugreifen würde.
>
> "SELECT ... WHERE DasBitFeld = " & VbBoolVar
Gerrit,
implizite Typkonvertierung kann unerwartete Effekte bringen:-)
Peter
Gerrit Kuhlendahl
"Peter Fleischer" <peter.fleis...@gmx.de> schrieb im Newsbeitrag
news:2vrmadF...@uni-berlin.de...
IKnow (im Gegensatz zu IUnknown :-) ). Allerdings liefern sowohl
Str als auch cStr auch unbrauchbare Werte. Somit ist also
eine eigene Konvertierungsfunktion fällig, da ja die (typkorrekte)
Umwandlung CStr(Cint(TRUE)) auch nur -1 liefern und somit wiederum
einen Fehler erzeugen würde, was ich (implizit) ja auch meinte.
:-))
Peter Fleischer
> "Peter Fleischer" <peter.fleis...@gmx.de> schrieb im
> Newsbeitrag news:2vrmadF...@uni-berlin.de...
>> Gerrit Kuhlendahl wrote:
>> ...
>>> Aber machen wir doch mal mit der Praxis weiter. Folgendes
>>> SQL-Statement liefert bei mir eine Fehler, wenn ich wie
>>> folgt auf ein BIT-Feld zugreifen würde.
>>>
>>> "SELECT ... WHERE DasBitFeld = " & VbBoolVar
>>
>> Gerrit,
>> implizite Typkonvertierung kann unerwartete Effekte bringen:-)
>
> IKnow (im Gegensatz zu IUnknown :-) ). Allerdings liefern sowohl
> Str als auch cStr auch unbrauchbare Werte.
Gerrit,
das ist aber unzulässiger Schluss. CStr ist auch in anderen Fällen
unbrauchbar, z.B.:
"SELECT ... WHERE Datum = " & CStr(VbDateVar)
Peter
Gerrit Kuhlendahl
"Peter Fleischer" <peter.fleis...@gmx.de> schrieb im Newsbeitrag
news:2vro34F...@uni-berlin.de...
[schnibbel]
>
> Gerrit,
> das ist aber unzulässiger Schluss. CStr ist auch in anderen Fällen
> unbrauchbar, z.B.:
>
> "SELECT ... WHERE Datum = " & CStr(VbDateVar)
Klar. Jedoch liefert in diesm Kontext auch die VB-Korrekt Umwandlung
CStr(CInt(vbBoolVar)) beim Wert TRUE einen unzulässigen Wert für ein
BIT-Feld.
Dieter Strassner
laßt doch mal Ingo zu Wort kommen ;-))
Er könnte doch seine Idee zur eigentlichen Frage doch noch in
praktikablerweise aufzeigen. oder?
Peter Götz
> > Gerrit,
> > das ist aber unzulässiger Schluss. CStr ist auch in anderen Fällen
> > unbrauchbar, z.B.:
> >
> > "SELECT ... WHERE Datum = " & CStr(VbDateVar)
>
> Klar. Jedoch liefert in diesm Kontext auch die VB-Korrekt Umwandlung
> CStr(CInt(vbBoolVar)) beim Wert TRUE einen unzulässigen Wert für ein
> BIT-Feld.
TRUE ist in VB nun mal als -1 definiert und da ändert weder ein cInt() noch
ein cStr() was daran.
"Select ... Where BitFeld = " & cStr(Abs(True))
sollte es dann aber schon tun. Und bei
"Select ... Where BitFeld = " & cst(Abs(False))
ändert das Abs() ohnehin nichts.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)
Gerrit Kuhlendahl
"Peter Götz" <gssg_...@t-online.de> schrieb im Newsbeitrag
news:uTwT3F9y...@TK2MSFTNGP10.phx.gbl...
> Hallo Gerrit,
>
> > > Gerrit,
> > > das ist aber unzulässiger Schluss. CStr ist auch in anderen Fällen
> > > unbrauchbar, z.B.:
> > >
> > > "SELECT ... WHERE Datum = " & CStr(VbDateVar)
> >
> > Klar. Jedoch liefert in diesm Kontext auch die VB-Korrekt Umwandlung
> > CStr(CInt(vbBoolVar)) beim Wert TRUE einen unzulässigen Wert für ein
> > BIT-Feld.
>
> TRUE ist in VB nun mal als -1 definiert und da ändert weder ein cInt()
noch
> ein cStr() was daran.
Sach ich doch die ganze Zeit! Deshalb paßt's ja eben auch nicht für
den Feldtyp BIT.
>
> "Select ... Where BitFeld = " & cStr(Abs(True))
>
> sollte es dann aber schon tun. Und bei
Eben. Also eine eigene Konverterfunktion, wie auch von mir angemerkt.
Und damit bestätigst Du ja auch letztlich das, worum es hier ursprünglich
geht (Posting von Ingo am 12.11. 18:26) - Das es beim BIT-Feld des
SQL-Servers eben nicht nur mit einer definierten Konstante getan ist
sondern das dort ein ganz anderer Ansatz als in VB/JET dahinter
steckt.
Ingo Moch
Dieter Strassner meint:
> laßt doch mal Ingo zu Wort kommen ;-))
> Er könnte doch seine Idee zur eigentlichen Frage doch
> noch in praktikablerweise aufzeigen. oder?
Ihr seit zu sehr bei VB (das war nur ein Bespiel von mir,
dass auch ohne expliziten Boolean-Datentyp True/False
geht) ...
Der SQL-Server (mit dem ich noch nicht in Kontakt
gekommen bin) soll eine SQL-Statement a'la "... WHERE
foo = TRUE ..." interpretieren koennen. SQl-Server
stellt Boolean mit den Datentyp BIT da. Also muesste
der SQL-Server dazu gebracht werden, TRUE als
1 (Datentyp BIT) zu "mappen". Demensprechend fehlt
den SQL-Server nur die Interpretation der Konstanten
TRUE und FALSE. _Wenn_ es im SQL-Server moeglich
ist, globale Konstanten zu definieren (bei Oracle
koennte das zumindest mit einer Funktion nachgebildet
werden) waere das kein Problem (weil ich nicht weiss
ob und wie das beim SQL-Server moeglich ist, habe ich
das explizit als theoretischen Ansatz markiert)
Nochmal: VB ist dabei sch...egal.
Ingo
Gerrit Kuhlendahl
"Ingo Moch" <myjunkmail....@gmx.de> schrieb im Newsbeitrag
news:cnsm7d.3...@hamster.mochnet.de...
> Hallo,
>
> Dieter Strassner meint:
>
> > laßt doch mal Ingo zu Wort kommen ;-))
> > Er könnte doch seine Idee zur eigentlichen Frage doch
> > noch in praktikablerweise aufzeigen. oder?
>
> Ihr seit zu sehr bei VB (das war nur ein Bespiel von mir,
> dass auch ohne expliziten Boolean-Datentyp True/False
> geht) ...
Nö. Es geht hier ja darum, mit VB auf den SQL-Server-
zuzugreifen.
>
> Der SQL-Server (mit dem ich noch nicht in Kontakt
> gekommen bin) soll eine SQL-Statement a'la "... WHERE
> foo = TRUE ..." interpretieren koennen. SQl-Server
> stellt Boolean mit den Datentyp BIT da. Also muesste
> der SQL-Server dazu gebracht werden, TRUE als
> 1 (Datentyp BIT) zu "mappen". Demensprechend fehlt
> den SQL-Server nur die Interpretation der Konstanten
> TRUE und FALSE. _Wenn_ es im SQL-Server moeglich
> ist, globale Konstanten zu definieren (bei Oracle
> koennte das zumindest mit einer Funktion nachgebildet
> werden) waere das kein Problem (weil ich nicht weiss
> ob und wie das beim SQL-Server moeglich ist, habe ich
> das explizit als theoretischen Ansatz markiert)
Aus meiner Sicht ein völlig falscher Ansatz. Es wird mit
VB auf einen Server zugegriffen (die Art des Servers, ob
nun DB, INet oder Bier ;-)) ist dabei völlig egal. Du
willst nun den Server mehr oder weniger mit Klimmzügen
an die Möglichkeiten von VB anpassen. Das halte ich ab-
solut nicht für gut.
Meiner Meinung nach richtiger wäre: Server XYZ kann dies
und jenes und hat das dokumentierte Verhalten "V". Damit
habe ich mich auf der VB-Seite abzufinden und meine Zu-
griffe entsprechend anzupassen.
>
> Nochmal: VB ist dabei sch...egal.
Eben nicht. ;-)
Ingo Moch
Gerrit Kuhlendahl meint:
> Aus meiner Sicht ein völlig falscher Ansatz. Es wird mit
> VB auf einen Server zugegriffen (die Art des Servers, ob
> nun DB, INet oder Bier ;-)) ist dabei völlig egal.
> u willst nun den Server mehr oder weniger mit Klimmzügen
> an die Möglichkeiten von VB anpassen. Das halte ich ab-
> solut nicht für gut.
Ein SQL-Statement ist aus VB-Sicht eine Zeichenfolge, und es
ist fuer VB vollkommen egal ob da "foo = 1", "foo = TRUE"
oder "foo = (1 = 1)" drinn steht. Da wird nichts an VB
angepasst.
> Meiner Meinung nach richtiger wäre: Server XYZ kann dies
> und jenes und hat das dokumentierte Verhalten "V". Damit
> habe ich mich auf der VB-Seite abzufinden und meine Zu-
> griffe entsprechend anzupassen.
Wenn es um irgendein exotisches Verhalten gehen wuerde,
wuerde ich dir zustimmen, aber TRUE/FALSE sehe ich als
Quasi-Standard.
Ingo