Hi,
Per D5 SP1, ADOExpress SP2 möchte ich auf eine Access2000-DB zugreifen. Verwendet wird MDAC 2.5. Die MDB liegt irgendwo im Netz und wird von max. fünf Anwendern gleichzeitig bearbeitet. In der DB ist eine buchähnliche Struktur abgebildet. Also z.B. Buch, Kapitel, Unterkapitel und Seiten. Daneben gibt es noch diverse andere Tabellen, die aber glaube ich in diesem Zusammenhang nicht wichtig sind. Auf jedenfall gibt es viele Master-Details.
Nach allem was ich hier gelesen habe, sollte ich
ADODataSets - Cursorlocation = clUseServer, CurosrType = ctKeyset und cmdType = cmdTableDirect
verwenden.
Da diese buchähnliche Struktur förmlich nach Master-Details schreit, würde ich dies auch gerne nutzen.
<br>
Das geht dann aber nicht mit clUseServer. Über ein entsprechendes SELECT (bei cmdType cmdText) läst sich die Beziehung auch abbilden und clUseServer beibehalten. Jedoch muss ich dann doch bei jedem scroll der Mastertabelle das SELECT neu ausführen (close/open oder refresh oder resync?)
Welche "Gefahren" gehen denn konkret von clUseClient aus? Was empfiehlt ihr?
Gruss und Danke<br>
Joerg
P.S.: Sind irgendwelche "Merkwürdigkeiten" von TADOTable.Locate bei
Detailtabellen bekannt?
Folgendes Verhalten tritt bei mir auf;
{ searchvalue ist IMMER in der phys. Tabelle vorhanden }
a.) bei aktiver m/d-Beziehung, searchvalue NICHT Bestandteil der Detailmenge<br>
Locate findet den record (liefert true) aber aktiviert ihn nicht.
BUG? Er sollte ihn aber nicht finden, denke ich.<br>
b.) bei aktiver m/d-Beziehung, searchvalue IST Bestandteil der Detailmenge.<br>
Locate findet den record (liefert true) und aktiviert ihn.
OK!<br>
c.) bei inaktiver m/d-Beziehung (per DisableControls)<br>
Gleiches Verhalten wie bei a.) Es sieht aus, als ob m/d immer noch
aktiv ist.<br>
d.) bei inaktiver m/d-Beziehung (per MasterSource = nil)<br>
Gleiches Verhalten wie bei b.)
Handelt es sich hier wirklich um einen (schweren) Bug oder habe ich etwas grundlegendes nicht verstanden? Kann jemand dieses Verhalten bestätigen?
Per D5 SP1, ADOExpress SP2 möchte ich auf eine Access2000-DB zugreifen. Verwendet wird MDAC 2.5. Die MDB liegt irgendwo im Netz und wird von max. fünf Anwendern gleichzeitig bearbeitet. In der DB ist eine buchähnliche Struktur abgebildet. Also z.B. Buch, Kapitel, Unterkapitel und Seiten. Daneben gibt es noch diverse andere Tabellen, die aber glaube ich in diesem Zusammenhang nicht wichtig sind. Auf jedenfall gibt es viele Master-Details.
Nach allem was ich hier gelesen habe, sollte ich
ADODataSets - Cursorlocation = clUseServer, CurosrType = ctKeyset und cmdType = cmdTableDirect
verwenden.
Da diese buchähnliche Struktur förmlich nach Master-Details schreit, würde ich dies auch gerne nutzen.
<br>
Das geht dann aber nicht mit clUseServer. Über ein entsprechendes SELECT (bei cmdType cmdText) läst sich die Beziehung auch abbilden und clUseServer beibehalten. Jedoch muss ich dann doch bei jedem scroll der Mastertabelle das SELECT neu ausführen (close/open oder refresh oder resync?)
Welche "Gefahren" gehen denn konkret von clUseClient aus? Was empfiehlt ihr?
Gruss und Danke<br>
Joerg
P.S.: Sind irgendwelche "Merkwürdigkeiten" von TADOTable.Locate bei
Detailtabellen bekannt?
Folgendes Verhalten tritt bei mir auf;
{ searchvalue ist IMMER in der phys. Tabelle vorhanden }
a.) bei aktiver m/d-Beziehung, searchvalue NICHT Bestandteil der Detailmenge<br>
Locate findet den record (liefert true) aber aktiviert ihn nicht.
BUG? Er sollte ihn aber nicht finden, denke ich.<br>
b.) bei aktiver m/d-Beziehung, searchvalue IST Bestandteil der Detailmenge.<br>
Locate findet den record (liefert true) und aktiviert ihn.
OK!<br>
c.) bei inaktiver m/d-Beziehung (per DisableControls)<br>
Gleiches Verhalten wie bei a.) Es sieht aus, als ob m/d immer noch
aktiv ist.<br>
d.) bei inaktiver m/d-Beziehung (per MasterSource = nil)<br>
Gleiches Verhalten wie bei b.)
Handelt es sich hier wirklich um einen (schweren) Bug oder habe ich etwas grundlegendes nicht verstanden? Kann jemand dieses Verhalten bestätigen?
Comment