Tabelle mit sich selbst verknüpfen

[oma]

Hallo,

ich hoffe nur, dass der Disput nun ausgetragen ist

Access ist eine tausendfach bewährte Datenbank, mit der in meinem Unternehmen sehr effizient gearbeitet wird und das ganze mit einnem vertretbaren Aufwand erstellt wurde. (Punkt)

Das vorher geprüft wurde (werden muss) ob Access in allen (oder in vielen ) Belangen den praktischen Anforderungen genügt, ist selbstverständlich. Das Access nur einen bestimmten Bereich abdeckt und es viele weit mächtigere Datenbanken gibt, ist ja wohl außer Frage.

Ich kann in einem Punkt Databases Argumentation verstehen.
Ich hatte mal ein generelles Problem mit Access u. habe mich an einen Bekannten (Informatiker) an der hiesigen Uni gewandt
Antwort: Ich beschäftige mich nur mit richtigen Datenbanken u. ich musste mir einen Vortag von theoretischen Überlegungen zu Datenbankkonzepten anhören. Mein Einwand, dass viele Dinge hierbei für mich bzw. meinen betrieblichen Anforderungen gar nicht relevant sind wurde ebenso verständnislos betrachtet wie ich die "allgemeinen theoretischen Erwägungen" betrachtet habe.

Nunja, ich habe mein Problem gelöst und arbeite weiterhin erfolgreich mit Access.

und zum Schluss: auch die kleinen Sticheleien sollte man lassen. In einem Disput sollte stets gegenseitiger Respekt herrschen

Hochachtungsvoll OMA

[Wurliwurm]

Hallo Oma,

bei uns in der Firma haben wir in der Arbeitsgruppe auch Access und das funktioniert eigentlich wunderbar (besonders die von mir erstellte Applikation natürlich). Allerdings ist sie auch langsam, wenn mehr als einer gleichzeitig darauf zurückgreift, zum Beispiel habe ich eine Sperrtabelle aufgebaut, wo erst nachgefragt wird, ob der Kunde gesperrt ist, dann ein Sperreintrag gesetzt wird und zuletzt noch einmal der letzte Stand frisch gezogen wird in das (ungebundene) Formular und erst dann die Felder editierbar werden (das ist eigentlich der Standard bei ERP-Systemen). Nachdem im Mehrbenutzerzugriff ein SQL-Befehl ungefähr 2 Sekunden braucht und man auch keine parallelen Threads benutzen kann, braucht es bis von Klicken auf den Editierknopf bis zum Bearbeitungsmodus etwa 6 Sekunden und wirkt damit etwas lahm. Das liegt konzeptbedingt am Access, nicht am Entwickler oder am Netzwerk, und das sollte man wissen.

Es ist halt bei Informatikern so, daß ein großer Teil des Faches Datenbanksysteme sich darum dreht, daß niemals inkonsistente Daten auftreten und niemals Daten verloren gehen. Und dazu wird viel Hirnschmalz eingesetzt. Der Standesdünkel der Informatiker lässt sie manchmal auf Access als Spielzeug herunterschauen und vielleicht bin ich selbst nicht frei davon.

[oma]

Hallo Johannes,

Es ist halt bei Informatikern so, daß ein großer Teil des Faches Datenbanksysteme sich darum dreht, daß niemals inkonsistente Daten auftreten und niemals Daten verloren gehen

das ist ja auch nachvollziehbar, wir haben aber mit Access im Unternehmen keine Probleme damit.

Der Standesdünkel der Informatiker lässt sie manchmal auf Access als Spielzeug herunterschauen

das ist eben der Unsinn: ein Maserati MC12 XX kann eben nicht mit dem Fiat 500 verglichen werden.
Und wenn ich ausschließlich ein Auto für den nahen Stadtverkehr brauche, kaufe ich das Spielzeug Fiat 500.

Naja, wir haben uns nun mal ausgetauscht und ich hoffe, du bleibst uns trotz der Krücke Access im Forum als Ratgeber erhalten!!!

Gruß Oma

[Josef]

[OT]

Nachdem im Mehrbenutzerzugriff ein SQL-Befehl ungefähr 2 Sekunden braucht und man auch keine parallelen Threads benutzen kann, braucht es bis von Klicken auf den Editierknopf bis zum Bearbeitungsmodus etwa 6 Sekunden und wirkt damit etwas lahm. Das liegt konzeptbedingt am Access, ...

2 Sekunden für eine Abfrage mit Index-Nutzung kommt mir aber auch für Jet etwas langsam vor. Das ldb-Locking als Ursache für die Bremse hast du aber schon ausgeschlossen, oder?

etwa 6 Sekunden und wirkt damit etwas lahm

Das würde ich nicht nur als lahm sondern als nciht bedienbar empfinden. 

mfg
Josef

[Wurliwurm]

2 Sekunden für eine Abfrage mit Index-Nutzung kommt mir aber auch für Jet etwas langsam vor. Das ldb-Locking als Ursache für die Bremse hast du aber schon ausgeschlossen, oder?

Indexe sind überall dort in der mdb, wo viel WHERE benutzt wird im SQL. In den Frontends wird nur über OLEDB-ADO zugegriffen. Ich habe eine zentrale ADODB.Connection, die bei Starten des Frontends geöffnet wird, die Daten lese ich ausschließlich mit dieser Connection und mit Read-Only, Forward-Only Recordsets in ungebundene Recordsets ein und mache die Datenbank-Recordsets gleich wieder zu. INSERT und UPDATE mache ich nur in ganz kurzen Transaktionen mit ADODB.Command. Sprich, die Connection ist immer offen und Recordsets sind immer nur nur kurz offen. Das habe ich so gemacht, damit man nur ganz wenig ändern müßte und dann auf eine "richtige" (bitte nicht hauen!) Datenbank gehen könnte.  Ist hier das ldb-Locking relevant? Ich dachte, das ist dann, wenn man immer Verbindungen bei jedem Lesezugriff extra auf- und zu macht. Eigentlich bräuchte ich den Locking-Mechanismus von Jet gar nicht unbedingt, weil ich ja die Sperrtabelle habe (allerdings könnte man sich natürlich in der Sperrtabelle in die Quere kommen, das verlagert das Problem nur, das ist mir bewußt).

etwa 6 Sekunden und wirkt damit etwas lahm

Das würde ich nicht nur als lahm sondern als nciht bedienbar empfinden.  

Man gewöhnt sich an alles, in der heutigen hektischen Zeit ist ein kurzer Moment des Innehaltens und der Vorfreude außerdem gut für Geist und Seele. Im Einzelzugriff ist das Teil ja auch flott. Natürlich würde ich mich freuen, wenn man das verbessern könnte und bin für Designtips immer dankbar. Wenn ich mit JBDC als Mehrbenutzer darauf zugreife, dann ist es übrigens nicht lahm.

Johannes

[Josef]

Ich habe eine zentrale ADODB.Connection

Ist das eine OLEBD-Verbindung direkt auf das Backend oder nur eine Referenz von CurrentProject.Connection?

Wenn es eine direkte Verbindung zum Backend ist, sollte meiner Meinung nach das ldb-Locking-Problem zumindest innerhalb von Aktionen dieser Connection beseitigt sein. Ich bin mir allerdings nicht sicher, ob das dann auch für die DAO-Verbindungen (verknüpfte Tabellen) helfen würde oder ob man für die DAO-Verbindung noch eine zusätzliche geöffnete DAO-Verbindung benötigt.

Im Einzelzugriff ist das Teil ja auch flott.

Bei so ein Verhalten verdächtige ich normalerweise sofort das ldb-locking. 

mfg
Josef

[Wurliwurm]

Ist das eine OLEBD-Verbindung direkt auf das Backend oder nur eine Referenz von CurrentProject.Connection?

Direkt auf das Backend:

Public conn As ADODB.Connection
Set conn = New ADODB.Connection
conn.CursorLocation = adUseClient
conn.Provider = "Microsoft.Jet.OLEDB.4.0"
conn .Open "Provider = Microsoft.Jet.OLEDB.4.0; Data Source =" & strBackendpfad & ""

Verknüpfte Tabellen in das Backend verwende ich nie und DAO verwende ich nur lokal im Frontend (nur selten, etwa um den Pfad zu Backend zu lesen beim Starten).

Grüße
Johannes

[Josef]

Hast du schon einmal adUseServer statt adUseClient ausprobiert? Anm.: Bei adUseClient wird nämlich adOpenForwardOnly zu adOpenStatic.
Dass das aber 2 Sekunden ausmacht, kann ich mir allerdings nicht vorstellen. 2 Sekunden für einen Index-Seek kommen mir viel zu lange vor, da muss meiner Meinung nach irgendetwas anderes im Server bzw. beim Dateizugriff schief laufen.


noch etwas zu

die Daten lese ich ausschließlich mit dieser Connection und mit Read-Only, Forward-Only Recordsets in ungebundene Recordsets ein

Wird dabei immer nur auf ein DS gefiltert oder sind auch mal tausende DS im Recordset?
Was meinst du eigentlich mit "in ungebunde Recordsets einlesen"? Kopierst du die Daten von Recordset A nach B?
Ich nehme an, dass du mit einem gebundenem Recordset die Daten abholst und dann die Verbindung kappst, oder?
Dein Satz klingt für mich aber irgendwie nach Kopieren.


aber zurück zum eigentlichen Problem:
Wenn ich dich richtig verstehe, tritt die Verzögerung nur dann auf, wenn mehrere User auf die DB zugreifen.
Wenn nur ein User auf die identische DB zugreift, läuft alles ruck-zuck ab.

Dieses Verhalten würde auf das ldb-Locking hindeuten - aber mit dem von dir gezeigten Code, sollte das bereits behoben sein.
Kann es sein, dass eventuell der Fileserver noch ein wenig mitspielt?
Die Tipps aus support.microsoft.com/kb/889588/de hast du schon alle durch?

mfg
Josef

[Wurliwurm]

Hast du schon einmal adUseServer statt adUseClient ausprobiert?

Ja, aber das ändert absolut nichts.

Wird dabei immer nur auf ein DS gefiltert oder sind auch mal tausende DS im Recordset?
Was meinst du eigentlich mit "in ungebunde Recordsets einlesen"? Kopierst du die Daten von Recordset A nach B?
Ich nehme an, dass du mit einem gebundenem Recordset die Daten abholst und dann die Verbindung kappst, oder?
Dein Satz klingt für mich aber irgendwie nach Kopieren.

Eigentlich wird immer nur ein DS eingelesen von der Datenbank, mit dem numerischen Primärschlüssel ("WHERE ID = 4711") und im Formular auf ein ungebundenes Recordset kopiert (wirklich kopiert rs1.addnew, rs1!feld = rs2!Feld1 etc) und dieses an die Form gebunden. Kann sein, daß das ein bißchen ungewöhlich ist, aber somit kann ich auch von XML einlesen oder sonst wie füllen, ich finde das sehr praktisch. Wenn man viele tausende DS liest etwa für einen Report, dann fällt der Unterschied auch nicht so auf und ist kein Thema.

Wenn ich dich richtig verstehe, tritt die Verzögerung nur dann auf, wenn mehrere User auf die DB zugreifen.
Wenn nur ein User auf die identische DB zugreift, läuft alles ruck-zuck ab.

Ja, im Einzelzugriff merkt man zwar noch einen Unterschied, ob man von C:\ liest oder vom Dateiserver liest, dieser ist aber nur spürbar, wenn man darauf achtet.

Kann es sein, dass eventuell der Fileserver noch ein wenig mitspielt?
Die Tipps aus support.microsoft.com/kb/889588/de hast du schon alle durch?

Ich hatte sie überflogen, werde sie mir noch einmal zu Gemüte führen. Ich fürchte aber, das ich da nicht soviel ändern darf und die Leute haben sich außerdem schon an die Langsamkeit gewöhnt. Ich habe schon als Ersatz einen Client-Prototyp in Java halb fertig (ist aber mehr für mich als Beschäftigung wenn es mal ruhiger zugeht), mit JBDC ist das gar nicht lahm, auch nicht im Mehrbenutzerzugriff auf Jet. Wenn man die Aktualisierung in Threads im Hintergrund machen kann und viel puffert, dann muß man gar nicht mehr warten, wirkt gefühlte 1000 mal schneller.

Auf jeden Fall vielen lieben Dank für deine Beratung. :-)
Johannes

[Josef]

Bezüglich Geschwindigkeit:
Ich führte gestern einen Test mit ein paar virtuellen Maschinen durch, in denen eine Anwendung lief, die auf ein gemeinsames Backend und auf die gleiche Tabelle (mit 2 Mio. DS) zugriff.
Ergebnis: ein <code>select * from testtabelle where id = Zufallszahl_zwischen_1_und2Mio</code> lief in ein paar Millisekunden (alles unter 1/10 sec) ab.

Eigentlich wird immer nur ein DS eingelesen von der Datenbank, mit dem numerischen Primärschlüssel ("WHERE ID = 4711") und im Formular auf ein ungebundenes Recordset kopiert (wirklich kopiert rs1.addnew, rs1!feld = rs2!Feld1 etc) und dieses an die Form gebunden. Kann sein, daß das ein bißchen ungewöhlich ist, aber somit kann ich auch von XML einlesen oder sonst wie füllen, ich finde das sehr praktisch.

Aber warum treibst du den Aufwand, um alles noch einmal von einem Recordset in ein anders zu kopieren? Ich hätte einfach die Referenz des Recordsets übergeben, bei dem ich zuvor die Verbindung zur DB gekappt hätte.

mit JBDC ist das gar nicht lahm

JDBC nutzt doch auch die Jet-Engine, oder? Falls das der Fall ist, wäre interessant, was ADODB/OLEDB anders macht.

Auf jeden Fall vielen lieben Dank für deine Beratung.

Naja, Beratung würde ich das nicht nennen - höchsten Mitraten.

mfg
Josef

[Wurliwurm]

Aber warum treibst du den Aufwand, um alles noch einmal von einem Recordset in ein anders zu kopieren? Ich hätte einfach die Referenz des Recordsets übergeben, bei dem ich zuvor die Verbindung zur DB gekappt hätte.

Zum Teil habe ich andere Datentypen (String in der Datenbank wegen Kompatibilität zum DBMS, Boolean im ungebundenen Recordset), zum Teil zusätzliche Felder, die rein mengenorientiert vom SQL aus nicht berechnet werden könnten.

JDBC nutzt doch auch die Jet-Engine, oder? Falls das der Fall ist, wäre interessant, was ADODB/OLEDB anders macht.

Wundern tue ich mich auch. Heute ist übrigens alles schnell, auch im Mehrbenutzerzugriff, man kommt schneller in den Bearbeitungsmodus, als daß man "Apfelkuchen" sagen kann.

Grüße
Johannes