CursorLocation = clUseServer bei Access

[Delphi_Fanatic]

Wie das Thema schon sagt : Ich möchte einen server-seitigen Daten-Cursor
im Zusammenhang mit MS Access benutzen.
Ist grundsätzlich möglich, das ADOConnection-Object lässt sich jedenfalls entsprechend einrichten.

Frage : Hat jemand von Euch Erfahrungen mit Server-Seitigen Daten-Cursorn bei Access ? Könnte es da Probleme geben in Bezug auf Stabilität und Performance ?

(P.S. und erzählt mir jetzt bitte nicht, dass es besser wäre, lieber lieber gleich Microsoft SQL-Server oder Ähnliches zu benutzen - das weiss ich auch ... da besteht jemand auf Access, also muss er es auch bekommen.)

[pjuk]

Delphi-Quellcode:

procedure TForm.ADODataSet1AfterOpen(DataSet: TDataSet);
begin
  if ADODataSet1.CursorLocation = clUseServer then
    StatusBar1.SimpleText := 'clUseServer';
end;

so hab ichs gelöst

vor- und nachteile?! gute frage - habs noch nicht getestet xD

[shmia]

Zitat von Delphi_Fanatic:

Ich möchte einen server-seitigen Daten-Cursor
im Zusammenhang mit MS Access benutzen.
Ist grundsätzlich möglich, das ADOConnection-Object lässt sich jedenfalls entsprechend einrichten.

Frage : Hat jemand von Euch Erfahrungen mit Server-Seitigen Daten-Cursorn bei Access ? Könnte es da Probleme geben in Bezug auf Stabilität und Performance ?

Ich habe festgestellt, dass Server-Seitige Cursor bei Access (Jet Engine 4) schneller als Client-Seitige Cursor arbeiten.
Da die Jet-Engine mit ihren Datenpuffern immer auf dem Client-Rechner liegt, würde es bei Client-Seitigen
Cursorn zu doublebuffering kommen.

Der Cursortyp muss vor dem Öffnen gesetzt werden; AfterOpen ist zu spät!!

[Bernhard Geyer]

Bei Access sollte man immer clUseServer nehmen (Speicherverlust bei Ado (Beitrag von A. Kosch)

[Delphi_Fanatic]

Danke für die Hilfe, Danke insbesondere auch für den Link.

Werde mich demnächst auch mal im Entwickler-Forum anmelden.

P.S. Der Typ da aus dem Entwickler-Forum hat ja echt "Mut" : 400.000 Datensätze in
eine Access-Datenbank zu speichern ... also da würde bei mir ja der Spass aufhören.
Ich halte Access für geeignet bei Datenmengen bis maximal 70.000 - 80.000 Datensätze.

Bei Access2000 gibt es - soweit ich weiss - ohnehin eine physische Speichergrenze
von 128.000 Datensätzen pro Tabelle. Ich weiss nicht, wie es bei der Nachfolger-Version
von Access2000 ist....

[pjuk]

hallo,


naja dazu muss man sagen, mut haben oder was in einer accesdb fortlaufen lassen ist wiederum was ganz anderes.

wenn du in einem betrieb arbeitest und für die was schreiben musst das ihre accessdb unterstützt kannst du denen nicht mit sql kommen ^^

gibt eben dinge die bereits falsch angefangen wurden jedoch so fortgeführt werden müssen.

[grayfox]

Zitat:

Bei Access2000 gibt es - soweit ich weiss - ohnehin eine physische Speichergrenze
von 2 GB pro Tabelle

nachdem ich einige tabellen mit mehr als 5 mio datensätzen habe, erscheint mir deine obergrenze von 128.000 etwas zu niedrig gegriffen

mfg, stefan

[Robert_G]

Zitat von grayfox:

Zitat:

Bei Access2000 gibt es - soweit ich weiss - ohnehin eine physische Speichergrenze
von 2 GB pro Tabelle

nachdem ich einige tabellen mit mehr als 5 mio datensätzen habe, erscheint mir deine obergrenze von 128.000 etwas zu niedrig gegriffen

mfg, stefan

5 mio. Datensätze in einer M$ JET-Tabelle?
Warum denn das? Lass doch nur mal gleichzeitig einen anderen Klient auf den gleichen Datensatz zugreifen (Bei Desktop DBs kann man das nunmal nicht vollständig verhindern ) -> *boom*
Ich wünsche viel Spass beim Suchen der beschädigten Einträge.
Ich hatte mal vor einer halben Ewigkeit (Ich war 15, 16, 17,... habs wohl verdrängt... ) mit Jet zu tun. Da hatte ich mehrfach das obengenannte Problem bekommen. Da Jet seit damals nur minimal, wenn überhaupt , weiterentwickelt wurde dürfte das immer noch gelten.

BTW: Es gibt keine Access DBs
Access == eingeschränkte klicki-Bunti-Oberfläche für eine eingeschränkte Desktop DB namens Jet...