Boolean typ in Tabellenspalte richtig anzeigen

[Stephan Menzel]

Hallo,

ich habe ein FE in Access 2003 erstellt für einen mysql Server,
per ADO Verbindung, mein Problem ist nun das wenn ich ein
Recordset öffne und dieses dann einen Listenfeld zuweise, werden
Booleanwerte immer Falsch angezeigt (z.B.mit 13568 oder 24833 oder
-24063)! In MySql ist das Feld als tinyint(1) deklariert!
Wenn ich die Tabelle verknüpfe, wird der Wert mit 0 oder 1 angezeigt!
Kennt das Problem jemand?

cu Stephan

[Ulrich Haarmeyer]

Hallo Stephan

Post by Stephan Menzel
Hallo,
ich habe ein FE in Access 2003 erstellt für einen
mysql Server, per ADO Verbindung, mein Problem ist
nun das wenn ich ein Recordset öffne und dieses
dann einen Listenfeld zuweise, werden Booleanwerte
immer Falsch angezeigt (z.B.mit 13568 oder 24833
oder -24063)! In MySql ist das Feld als tinyint(1)
deklariert!

Der korrekte Datentyp für boolsche Werte auf dem
SQL-Server ist BIT und nicht TINYINT.
Der Datentyp BIT kann aber keine negativen Werte
speichern. Du müßtest dann in der Abfrage
0-BITWert verwenden, um die von Access verwendete
-1 für True zu erhalten.

Post by Stephan Menzel
Wenn ich die Tabelle verknüpfe, wird der Wert
mit 0 oder 1 angezeigt!
Kennt das Problem jemand?

In der Form nicht, aber stell mal in der Tabelle
den Datentyp um. Ein Bit kann nun mal nichts
anderes als 0 oder 1 liefern.

Gruß
Uli

[Stephan Menzel]

Post by Ulrich Haarmeyer

Post by Stephan Menzel
ich habe ein FE in Access 2003 erstellt für einen
mysql Server, per ADO Verbindung, mein Problem ist
nun das wenn ich ein Recordset öffne und dieses
dann einen Listenfeld zuweise, werden Booleanwerte
immer Falsch angezeigt (z.B.mit 13568 oder 24833
oder -24063)! In MySql ist das Feld als tinyint(1)
deklariert!

Der korrekte Datentyp für boolsche Werte auf dem
SQL-Server ist BIT und nicht TINYINT.

Ich meinte aber den MySql Server! Da gibt es zwar auch Bit aber ich
denke TINYINT(1) ist für einen Boolschen wert schon richtig!

Post by Ulrich Haarmeyer
Der Datentyp BIT kann aber keine negativen Werte
speichern. Du müßtest dann in der Abfrage
0-BITWert verwenden, um die von Access verwendete
-1 für True zu erhalten.

Post by Stephan Menzel
Wenn ich die Tabelle verknüpfe, wird der Wert
mit 0 oder 1 angezeigt!
Kennt das Problem jemand?

In der Form nicht, aber stell mal in der Tabelle
den Datentyp um. Ein Bit kann nun mal nichts
anderes als 0 oder 1 liefern.

Was soll es auch anderes Liefern? Es soll ja nur den boolschen Wert
richtig im Listenfeld mit 0 oder 1 darstellen und nicht irgendwelche
Zahlen anzeigen!

cu Stephan

[Josef Poetzl]

Hallo!

Post by Stephan Menzel
ich habe ein FE in Access 2003 erstellt für einen mysql Server,
per ADO Verbindung, mein Problem ist nun das wenn ich ein
Recordset öffne und dieses dann einen Listenfeld zuweise, werden
Booleanwerte immer Falsch angezeigt (z.B.mit 13568 oder 24833 oder
-24063)! In MySql ist das Feld als tinyint(1) deklariert!
Wenn ich die Tabelle verknüpfe, wird der Wert mit 0 oder 1 angezeigt!
Kennt das Problem jemand?

Ist mir bis jetzt noch nicht aufgefallen, besteht aber auch in meiner
Testanwendung. Es ist zum Glück nur eine falsche Anzeige. Als ich auf
den Feldwert zugriff, wurde der richtige Wert verwendet.
Ein direkter Zugriff auf ein ADO-Recordset liefert auch den richtigen
Wert.

Ich vermute, dass es ein Problem mit dem Wertebereich gibt.
Vielleicht versucht ADO einen unsigned tinyint zu verwenden.
Grund: gibt man in ein Formular die Zahl -1 ein, so wird nach dem
Aktualisieren 255 angezeigt.
Wenn man als Datentyp tinyint(1) unsigned verwendet, gibt es kein
Problem.

mfg
Josef

[Stephan Menzel]

Post by Josef Poetzl

Post by Stephan Menzel
ich habe ein FE in Access 2003 erstellt für einen mysql Server,
per ADO Verbindung, mein Problem ist nun das wenn ich ein
Recordset öffne und dieses dann einen Listenfeld zuweise, werden
Booleanwerte immer Falsch angezeigt (z.B.mit 13568 oder 24833 oder
-24063)! In MySql ist das Feld als tinyint(1) deklariert!
Wenn ich die Tabelle verknüpfe, wird der Wert mit 0 oder 1 angezeigt!
Kennt das Problem jemand?

Ist mir bis jetzt noch nicht aufgefallen, besteht aber auch in meiner
Testanwendung. Es ist zum Glück nur eine falsche Anzeige. Als ich auf
den Feldwert zugriff, wurde der richtige Wert verwendet.
Ein direkter Zugriff auf ein ADO-Recordset liefert auch den richtigen
Wert.
Ich vermute, dass es ein Problem mit dem Wertebereich gibt.
Vielleicht versucht ADO einen unsigned tinyint zu verwenden.
Grund: gibt man in ein Formular die Zahl -1 ein, so wird nach dem
Aktualisieren 255 angezeigt.
Wenn man als Datentyp tinyint(1) unsigned verwendet, gibt es kein
Problem.

Ja jetzt geht es mit unsigned!
Wie müsste ich die SQL Abfrage formulieren das dann "ja" und "nein"
Angezeigt wird und nicht 0 und 1?

cu Stephan

[Josef Poetzl]

Hallo!

Post by Stephan Menzel
Ja jetzt geht es mit unsigned!

Falls Du die übliche Access-Funktionalitäten für ein Ja/Nein-Feld
verwenden willst, dann ist es sicherer int zu verwenden.
Grund: Ja (in Access) = -1

Wenn dann einmal der ODBC-Connector und Access besser
zusammenarbeiten, kannst Du immer noch auf tinyint umsteigen.

Post by Stephan Menzel
Wie müsste ich die SQL Abfrage formulieren das dann "ja" und "nein"
Angezeigt wird und nicht 0 und 1?

Das würde ich nicht in der Abfrage machen, sondern im Formular bzw. im
Bericht per Format-Eigenschaft.

Falls es aber unbedingt per Abfrage sein muss:
MySQL-Syntax:
select case when JaNeinFeld=0 then 'Nein' else 'Ja' END AS TextJaNein
from ...

Access-Abfrage:
select IIF(JaNeinFeld=0,'Nein','Ja') AS TextJaNein
from ...


mfg
Josef

[Stephan Menzel]

Post by Josef Poetzl
Falls Du die übliche Access-Funktionalitäten für ein Ja/Nein-Feld
verwenden willst, dann ist es sicherer int zu verwenden.
Grund: Ja (in Access) = -1
Wenn dann einmal der ODBC-Connector und Access besser
zusammenarbeiten, kannst Du immer noch auf tinyint umsteigen.

Post by Stephan Menzel
Wie müsste ich die SQL Abfrage formulieren das dann "ja" und "nein"
Angezeigt wird und nicht 0 und 1?

Das würde ich nicht in der Abfrage machen, sondern im Formular bzw. im
Bericht per Format-Eigenschaft.
select case when JaNeinFeld=0 then 'Nein' else 'Ja' END AS TextJaNein
from ...
select IIF(JaNeinFeld=0,'Nein','Ja') AS TextJaNein
from ...

Da es nur zur Azeige in einem Listenfeld Verwendung findet,
reicht die Ja/Nein Ausgabe!
Wenn ich das ganze als Pass-Through-Abfrage laufen lasse, geht es,
öffne ich aber ein Recordset und weise dies mit
set listenfeld=rst zu kommt die Fehlermeldung "Das eingegebene Objekt
ist keine gültige Recordset-Eigenschaft.".
Egal ob ich in der Abfrage des rst's if oder case verwende!
Es sieht so aus als wird der erstellten Spalte kein Datentyp richtig
zugewiesen!

cu Stephan

[Josef Poetzl]

Hallo!

Post by Stephan Menzel

Post by Josef Poetzl
select case when JaNeinFeld=0 then 'Nein' else 'Ja' END AS TextJaNein
from ...

[...]

Post by Stephan Menzel
Wenn ich das ganze als Pass-Through-Abfrage laufen lasse, geht es,
öffne ich aber ein Recordset und weise dies mit
set listenfeld=rst zu kommt die Fehlermeldung "Das eingegebene Objekt
ist keine gültige Recordset-Eigenschaft.".
Egal ob ich in der Abfrage des rst's if oder case verwende!

... weil diese Fehlermeldung nicht von der SQL-Anweisung kommt.
Ich vermute, dass /rst.CursorLocation=adUseClient/ fehlt.

mfg
Josef

[Stephan Menzel]

Post by Josef Poetzl
... weil diese Fehlermeldung nicht von der SQL-Anweisung kommt.
Ich vermute, dass /rst.CursorLocation=adUseClient/ fehlt.

Du hattest Recht ich hatte adUseServer genommen!
Warum muss ich die CursorLocation da auf dem Client belassen?

Danke für deine Hilfe!
cu Stephan

[Stephan Menzel]

Hallo,

gleich noch ne frage, warum kann ich die .Orderby eigenschaft
nur einmal setzen wenn ich ein Recordset durch eine ADO Connection
zugewiesen habe!?
Anschließen kommt ein Laufzeitfehler 31
"Der Datenprovider konnt nicht initialisiert werden."


cu Stephan

[Josef Poetzl]

Hallo!

Post by Stephan Menzel
gleich noch ne frage, warum kann ich die .Orderby eigenschaft
nur einmal setzen wenn ich ein Recordset durch eine ADO Connection
zugewiesen habe!?
Anschließen kommt ein Laufzeitfehler 31
"Der Datenprovider konnt nicht initialisiert werden."

Ich kann es mir (noch) nicht vorstellen, warum es bei Dir nicht
funktioniert.
In meiner Test-mdb gibt es kein Problem mit Me.OrderBy.

Wird bei Dir OrderBy richtig durchgeführt, wenn Du eine verknüpfte
Tabelle verwendest?

mfg
Josef

[Stephan Menzel]

Post by Josef Poetzl

Post by Stephan Menzel
gleich noch ne frage, warum kann ich die .Orderby eigenschaft
nur einmal setzen wenn ich ein Recordset durch eine ADO Connection
zugewiesen habe!?
Anschließen kommt ein Laufzeitfehler 31
"Der Datenprovider konnt nicht initialisiert werden."

Ich kann es mir (noch) nicht vorstellen, warum es bei Dir nicht
funktioniert.
In meiner Test-mdb gibt es kein Problem mit Me.OrderBy.
Wird bei Dir OrderBy richtig durchgeführt, wenn Du eine verknüpfte
Tabelle verwendest?

Ja bei einer verknüpften tabelle gibt es kein problem.
Also die Abfolge ist
set form.recordset=rst
form.orderby="...nach irgendwas..."
form.orderbyon=true
alles ok bis dahin!

Wenn ich jetzt die Eigenschaft Form.Orderby aber nochmal ändern möchte
tritt der Fehler auf.
entweder bei form.orderby="..." oder wenn ich erst
"form.orderbyOn = false" setze und dann
<form.orderby="..."> setze, tritt der Fehler dann bei
"form.orderbyon=true" auf

cu Stephan

[Josef Poetzl]

Hallo!

Post by Stephan Menzel

Post by Josef Poetzl

Post by Stephan Menzel
"Der Datenprovider konnt nicht initialisiert werden."

[...]

Post by Stephan Menzel

Post by Josef Poetzl
Wird bei Dir OrderBy richtig durchgeführt, wenn Du eine verknüpfte
Tabelle verwendest?

Ja bei einer verknüpften tabelle gibt es kein problem.
Also die Abfolge ist
set form.recordset=rst
form.orderby="...nach irgendwas..."
form.orderbyon=true
alles ok bis dahin!
Wenn ich jetzt die Eigenschaft Form.Orderby aber nochmal ändern möchte
tritt der Fehler auf.
entweder bei form.orderby="..." oder wenn ich erst
"form.orderbyOn = false" setze und dann
<form.orderby="..."> setze, tritt der Fehler dann bei
"form.orderbyon=true" auf

Da es bei mir funktioniert: Könnte es andere Ursachen geben?
Versuche einmal vor dem 2. OrderBy auf das Recordset-Objekt
zuzugreifen. Vielleicht scheitert auch das.

mfg
Josef

P.S.
So testete ich:

'RS einstellen:
Private Sub Form_Open(Cancel As Integer)
Dim cnn As ADODB.Connection
Dim rst As ADODB.Recordset
Set cnn = New ADODB.Connection
cnn.Open "Provider=MSDASQL;DRIVER={MySQL ODBC 3.51 Driver};DATABASE=testdb;SERVER=192.168.0.5;UID=user;pwd=pwd;"
Set rst = New ADODB.Recordset
rst.CursorLocation = adUseClient
rst.Open "SELECT * from datentypen order by zahl_int2", cnn, adOpenDynamic
Set Me.Recordset = rst
Set rst = Nothing
End Sub

'Schaltflächen zum Sortieren:
Private Sub cmdSort1_Click()
Me.OrderBy = "textfeld"
Me.OrderByOn = True
End Sub
Private Sub cmdSort2_Click()
Me.OrderBy = "zahl_int1"
Me.OrderByOn = True
End Sub

[Stephan Menzel]

Post by Josef Poetzl
Da es bei mir funktioniert: Könnte es andere Ursachen geben?
Versuche einmal vor dem 2. OrderBy auf das Recordset-Objekt
zuzugreifen. Vielleicht scheitert auch das.

nach dem ich mir deine TestDB erstellt hatte und das Access FE
zusammengebastelt war, war ich erstaunt wie schön einfach das doch
alles Funktionierte!
Dann suche ich in meinem anderen FE nach einem Fehler aber finde
nun keinen!
Ich hatte dann selbst das Login Form noch in die TestDB eingebunden,
das auch alles gleich ist, aber nix zu machen, der Fehler tritt nur in
dem anderen FE auf!

Wenn ich im direktbereich mit
debug.print form_Liste.Recordset!frmIndex zugreife, ist dies auch nach
dem auftreten des Fehlers noch möglich, es wird aus dem Endlosformular
immer der Korrekte frmIndex angegeben, von dem Datensatz der gerade
Ausgewählt wurde!

cu Stephan

[Josef Poetzl]

Hallo!

Post by Stephan Menzel
nach dem ich mir deine TestDB erstellt hatte und das Access FE
zusammengebastelt war, war ich erstaunt wie schön einfach das doch
alles Funktionierte!

:-)

Post by Stephan Menzel
Dann suche ich in meinem anderen FE nach einem Fehler aber finde
nun keinen!

Vielleicht gibt es gar keinen Fehler im Code. Importiere einmal alle
Objekte in eine neue mdb. Möglicherweise ist dann das Problem gelöst.

Post by Stephan Menzel
Ich hatte dann selbst das Login Form noch in die TestDB eingebunden,
das auch alles gleich ist, aber nix zu machen, der Fehler tritt nur in
dem anderen FE auf!

Wie hängt das Login-Form mit OrderBy zusammen?

mfg
Josef

[Stephan Menzel]

Hallo!

Post by Josef Poetzl

Post by Stephan Menzel
nach dem ich mir deine TestDB erstellt hatte und das Access FE
zusammengebastelt war, war ich erstaunt wie schön einfach das doch
alles Funktionierte!

:-)

Post by Stephan Menzel
Dann suche ich in meinem anderen FE nach einem Fehler aber finde
nun keinen!

Vielleicht gibt es gar keinen Fehler im Code. Importiere einmal alle
Objekte in eine neue mdb. Möglicherweise ist dann das Problem gelöst.

Nein das problem besteht weiterhin!
Mir ist jetzt noch etwas aufgefallen! Da ich dieses Formular in einem
unterformular habe, habe ich mir ein Leeres Formular, nur mit einem
Unterformular erstellt und mein Testformular eingebunden! Und siehe
da ab da tritt auch der Fehler auf! Ist das bei Dir auch der Fall?

Post by Josef Poetzl

Post by Stephan Menzel
Ich hatte dann selbst das Login Form noch in die TestDB eingebunden,
das auch alles gleich ist, aber nix zu machen, der Fehler tritt nur in
dem anderen FE auf!

Wie hängt das Login-Form mit OrderBy zusammen?

Ich wollte so nur ausschließen das es nicht an dem Anmeldevorgang
liegt!

vielen Dank für deine Unterstützung

cu Stephan

[Josef Poetzl]

Hallo!

Post by Stephan Menzel
Mir ist jetzt noch etwas aufgefallen! Da ich dieses Formular in einem
unterformular habe, habe ich mir ein Leeres Formular, nur mit einem
Unterformular erstellt und mein Testformular eingebunden! Und siehe
da ab da tritt auch der Fehler auf! Ist das bei Dir auch der Fall?

Ja, dann bekomme ich auch die Fehlermeldung.
Ich habe auch schon eine Problem-/Umgehung/ gefunden. Diese verstehe
ich zwar nicht, aber sie wirkt. ;-)

Vor jedem Orderby schreibst Du:
Set Me.Recordset = Me.Recordset

Falls Du es "sauber" lösen willst, dann könntest Du das OrderBy in ein
SQL-Statement einbinden und dem Formular immer ein neues Recordset
zuweisen.

mfg
Josef

[Stephan Menzel]

Post by Josef Poetzl
Falls Du es "sauber" lösen willst, dann könntest Du das OrderBy in ein
SQL-Statement einbinden und dem Formular immer ein neues Recordset
zuweisen.

Hm daran dachte ich auch schon. aber ich wollte nicht so viel Daten
zwischen Server und Client hin und her schicken!

cu Stephan