Access DB - Ja/Nein-Feld - Format

[renew]

Ich hab in einer Table in Access ein Ja/Nein Feld.

Wenn ich die Tabelle händisch erstelle und ein Ja/Nein Feld auswähle, wird automatisch als Format Ja/Nein eingetragen.
Wenn ich nun die Tabelle an ein Listfeld binde, erscheint bei dem Wert False ein "Nein" und bei True ein "Ja"

Jetzt erstelle ich solche Tabellen aber auch zur Laufzeit via SQL Abfrage (Create Table tablename ([Attrib1] YesNo, ....)
Nur da wird dann kein Ausgabeformat bestimmt und ich seh im Listfeld nur einen 0er für False und einen -1er für True.

Und das is net wirklich repräsentativ.
Weiß von euch vielleicht jemand, wie ich das ganze via VB zur Laufzeit einstellen kann?

Ich dank euch schon mal.

[Seidl]

Vergleich mal in den beiden Tabellen die Properties für das bewusste Feld. Dort sollte eigentlich sowas machbar sein.

---------------------------------------
Public Sub Test()
Dim wrk As DAO.Workspace
Dim db As DAO.Database
Dim Properties As DAO.Properties
Set wrk = CreateWorkspace("", "Admin", "")
Set db = wrk.OpenDatabase(CurrentProject.FullName)
Set Properties = db.TableDefs("YourTable").Fields("YourField").Prop erties
End Sub

[renew]

Original geschrieben von Seidl
Vergleich mal in den beiden Tabellen die Properties für das bewusste Feld. Dort sollte eigentlich sowas machbar sein.

---------------------------------------
Public Sub Test()
Dim wrk As DAO.Workspace
Dim db As DAO.Database
Dim Properties As DAO.Properties
Set wrk = CreateWorkspace("", "Admin", "")
Set db = wrk.OpenDatabase(CurrentProject.FullName)
Set Properties = db.TableDefs("YourTable").Fields("YourField").Prop erties
End Sub

danke...

DAO hab ich bis jetzt nicht wirklich geschaut - ich bin eigentlich voll auf ADO(X).

Mit ADOX war ich schon auf der Table, aber da hab ich net wirklich was gefunden, außer den Standardeinstellungen.
Aber vielleicht gibt ja das "alte" DAO mehr her, in der Beziehung.

Danke auf alle Fälle.

[Seidl]

So schön ADO und ADOX auch sind (bzw. sein sollten) bin ich nicht wirklich ganz glücklich damit. Ich weiss, ich habe schon andere Statements hören lassen aber man lernt eben nie aus

Natürlich sind ADO und ADOX an sich eine schöne Sache aber es gibt da auch so einige Hacken. Dadurch, das ADOX für möglichst viele Systeme funktionieren soll, ist es natürlich sehr allgemein gehalten. Eigenschaften die einem einzelnen System zu eigen sind können da selbstverständlich nicht immer mit Einzug halten.

Wenn man unter Access wirklich in die Tiefe will, muss man sich oft genug mit DAO abplagen. Da führt leider kein Weg dran vorbei. Einzig für den Zugriff auf andere Datenbanksysteme ist ADO natürlich klar im Vorteil (wenn auch oft langsamer) da es als aktuelle Lösung auch noch in Zukunft weiter unterstützt werden wird.

[frazzz]

wie wäre ein updatetrigger auf diese spalten?

ifthenelse


so als workaround

[renew]

Original geschrieben von frazzz
wie wäre ein updatetrigger auf diese spalten?

ifthenelse


so als workaround

hab ich nix davon.

Weil ich die Tabelle direkt mit einer Abfrage an ein Listfeld binde. Es werden also direkt die Werte die in der Tabelle stehen in das Listfeld eingetragen.
Und wenn ich das nicht auf "Tabellenebene" einstellen kann (das mit dem Ja/Nein), dann steht halt leider 0 und -1 im Listfeld.

Inzwischen hat sich das ganze eh schon 3mal geändert und ist schon ganz anders, aber mich interessierts trotzdem noch.
Also werd ich mir das mit DAO anschaun.

Ich hab eh schon a bissl mit DAO gemacht (meine ersten Schritte in VB und DBs), aber mich in den letzten 1 1/2 Jahren eigentlich immer nur mit ADO beschäftigt.

BTW: DAO is schneller als ADO - das is ja komisch....

[Seidl]

Nicht unbedingt.

Mit einem Offroad-Wagen kannst du so ziemlich jede Strasse befahren aber auf dem ihm eigenen Terrain ist ein Rennflitzer bestimmt um einiges schneller.

ADO ist eben nicht auf Access spezialisiert und das muss sich natürlich irgendwo niederschlagen.

[renew]

Original geschrieben von Seidl
Nicht unbedingt.

Mit einem Offroad-Wagen kannst du so ziemlich jede Strasse befahren aber auf dem ihm eigenen Terrain ist ein Rennflitzer bestimmt um einiges schneller.

ADO ist eben nicht auf Access spezialisiert und das muss sich natürlich irgendwo niederschlagen.

is logisch....

müsste man halt man ein paar Vergleiche machen und schaun was schneller is.

[Seidl]

Hier ein paar Daten aus: "Microsoft Access Programmierung - Version 2002 (ISBN 3-86063-654-5)"

Im speziellen gehts um:

"Abbildung 9.30: Zeitmessung für Lokale Datenbank"
-------------------------------------------
ODBCDirect (Dynaset) - 65ms
ADO (ClientCursor, Static) - 48ms
ADO (ServerCursor, KeySet) - 20ms
ADO (ServerCursor, Static) - 28ms
DAO (Snapshot) - 19ms
DAO (Table) - 3ms
DAO (Dynaset) - 8ms
-------------------------------------------

und um:

"Abbildung 9.31: Zeitmessung für SQL-Server-Datenbank"
-------------------------------------------
ODBCDirect (Snapshot) - 1250ms
ODBCDirect (Dynamic) - 700ms
ODBCDirect (Dynaset) - 3500ms
ADO (ClientCursor, Static) - 250ms
ADO (ClientCursor, Keyset) - 250ms
ADO (ServerCursor, KeySet) - 20200ms
ADO (ServerCursor, Static) - 20000ms
-------------------------------------------

Die Werte stimmen vielleicht nicht ganz da ich sie auf die Schnelle aus den recht kleinen Diagrammen abgelesen habe. Man sieht aber auf jeden Fall, dass DAO unter Umständen durchaus Vorteile besitzt.

An dieser Stelle noch ein kleiner Textauszug der den Vergleich der Technologien abschliesst.

--------------------------------------------
Wie gesagt: Welche Technologie Sie schlussendlich nutzen, hängt auch davon ab, welches Problem Sie lösen möchten. Bei der Arbeit mit Access-Datenbanken sind die ADOs zwar teilweise langsamer, spätere Umstellungen auf einen SQL Server sind jedoch wesentlich einfacher realisierbar (denken Sie daran, den Cursortyp zu ändern, siehe obige Diagramme!).
--------------------------------------------


PS: Die zweiten Zeitmessungen habe ich nur der Vollständigkeit halber hinzugefügt, auch wenn DAO darin nicht vorkommt.

[renew]

Original geschrieben von Seidl
Hier ein paar Daten aus: "Microsoft Access Programmierung - Version 2002 (ISBN 3-86063-654-5)"

Im speziellen gehts um:

"Abbildung 9.30: Zeitmessung für Lokale Datenbank"
-------------------------------------------
ODBCDirect (Dynaset) - 65ms
ADO (ClientCursor, Static) - 48ms
ADO (ServerCursor, KeySet) - 20ms
ADO (ServerCursor, Static) - 28ms
DAO (Snapshot) - 19ms
DAO (Table) - 3ms
DAO (Dynaset) - 8ms
-------------------------------------------

und um:

"Abbildung 9.31: Zeitmessung für SQL-Server-Datenbank"
-------------------------------------------
ODBCDirect (Snapshot) - 1250ms
ODBCDirect (Dynamic) - 700ms
ODBCDirect (Dynaset) - 3500ms
ADO (ClientCursor, Static) - 250ms
ADO (ClientCursor, Keyset) - 250ms
ADO (ServerCursor, KeySet) - 20200ms
ADO (ServerCursor, Static) - 20000ms
-------------------------------------------

Die Werte stimmen vielleicht nicht ganz da ich sie auf die Schnelle aus den recht kleinen Diagrammen abgelesen habe. Man sieht aber auf jeden Fall, dass DAO unter Umständen durchaus Vorteile besitzt.

An dieser Stelle noch ein kleiner Textauszug der den Vergleich der Technologien abschliesst.

--------------------------------------------
Wie gesagt: Welche Technologie Sie schlussendlich nutzen, hängt auch davon ab, welches Problem Sie lösen möchten. Bei der Arbeit mit Access-Datenbanken sind die ADOs zwar teilweise langsamer, spätere Umstellungen auf einen SQL Server sind jedoch wesentlich einfacher realisierbar (denken Sie daran, den Cursortyp zu ändern, siehe obige Diagramme!).
--------------------------------------------


PS: Die zweiten Zeitmessungen habe ich nur der Vollständigkeit halber hinzugefügt, auch wenn DAO darin nicht vorkommt.

danke....

Passt jetzt zwar net 100%ig in das Thema, aber kennst du eine ausführlichere Erklärung über ADO Locktypes und Cursortypes? Weil das was ich dazu in der MSDN gefunden habe, ist net so wirklich viel. (es steht nur ganz kurz was drin)