Access-o-Mania

Hallo,

gibt es in Access eine Möglichkeit eine Tabelle mit sich selbst zu verknüpfen?

Genauere Erklärung:

Also ich habe eine Tabelle, in welcher bestimmte Daten über Personen stehen, also wie eine Kontaktdatenbank mit Name, Anschrift, E-Mail usw.
Jetzt habe ich aber auch ein Feld mit Ehepartner. Da möchte ich also bei allen Leuten, die verheiratet sind, den Ehepartner eintragen. Jetzt möchte ich aber nicht einfach den Namen eingeben, sondern ich würde dieses Feld gerne mit einer anderen Person (aus der selben Tabelle ! ) verknüpfen, damit ich genau sehe, wer mit wem verheiratet ist.

Ist das möglich.

Vielen Dank schon mal im Voraus für eure Tipps.

Gehen tut das schon, das ist Standard.

Die einfachste Lösung ist ein Feld Ehepartner mit Key, wo die Nummer des Ehepartners drin steht, allerdings muß auch beim Partner die gleiche Referenz drinstehen. Was Integritätsprüfungen bestrifft, so weiß ich nicht, ob Access das kann, die Constraints von Access sind eher rudimentär.

Beim Auswertungen (Queries) mußt Du dann Aliase verwenden zur Verknüpfung.

Alternative ist eine eigene Relation (Tabelle verheiratet) mit einem solchen Constraint, daß wirklich eine eineindeutige Beziehung modelliert wird (mindestens PK für eine Spalte und Unique-Constraint für die andere Spalte)

Grüße
Johannes

Hallo,
ich würde das andes lösen.
Erstelle eine weitere Tabelle in der 2x das Schlüsselfeld der einen Namenstabelle aufgenommen wird. Im Beziehungsfenster wird die Namenstabelle 2x aufgenommen.
Wenn man in die Zuordnungstabelle noch eine Datum und das Verwandschaftsverhältis (ebenfalls Tabelle erstellen) mit aufnimmt kann man mit einer Personentabelle alle Verhältnisse erfassen. Kinder, Geschwister, Lebenspartener, Ehepartner usw.

Hallo,

ich würde zur MzKlMu - Variante raten, die von Wurliwurm ist zu steif.

Mit der Lösung von MzKlMu ist es auch möglich der Scheidungsrate Rechnung zu tragen (Datum zum Verhältnis machts möglich!)  ;D

Greets

p.s. @Wurliwurm

ZitatWas Integritätsprüfungen bestrifft, so weiß ich nicht, ob Access das kann, die Constraints von Access sind eher rudimentär

Dir gefällt der SQL Server besser gelle?   ;D ;)

Zitat von: database am August 16, 2010, 21:20:17
Hallo,

ich würde zur MzKlMu - Variante raten, die von Wurliwurm ist zu steif.

Mit der Lösung von MzKlMu ist es auch möglich der Scheidungsrate Rechnung zu tragen (Datum zum Verhältnis machts möglich!)  ;D

Greets

p.s. @Wurliwurm

ZitatWas Integritätsprüfungen bestrifft, so weiß ich nicht, ob Access das kann, die Constraints von Access sind eher rudimentär

Dir gefällt der SQL Server besser gelle?   ;D ;)

Eigene Relation ist sicher besser als nur ein extra Feld. Wenn aber geschiedene Ehen und auch andere Verwandschaftsbeziehungen modelliert werden sollen, dann wird das natürlich schon erheblich aufwändiger, es kommt darauf an, ob man das braucht.

Ein richtiges Datenbanksystem ist sicherlich besser, was (u.a.) Integritätsbedingungen betrifft, der Unterschied zu Access ist wie der zwischen einem einmotorigen Sportflugzeug und einem Airbus A380.

Ich finde, man sollte Access nicht überstrapazieren. Genausowenig wie Exceltapeten sinnvoll eine Desktopdatenbank wie Access ersetzen können, kann Access eine richtige Datenbank ersetzen. Als Frontend ist es aber sehr nützlich.

Hallo,

Zitatkann Access eine richtige Datenbank ersetzen.

Warum soll Access keine datenbank sein?
Auch mit Access lassen sich einwandfreie DBs erstellen, die den Regeln einer realtionalen Datenbank entsprechen. Und kompfortabel ist die Entwicklungsumgebung auch.

Zitat von: MzKlMu am August 17, 2010, 14:06:20
Hallo,

Zitatkann Access eine richtige Datenbank ersetzen.

Warum soll Access keine datenbank sein?
Auch mit Access lassen sich einwandfreie DBs erstellen, die den Regeln einer realtionalen Datenbank entsprechen. Und kompfortabel ist die Entwicklungsumgebung auch.

Öhm... ich wollte da keine hitzige Diskussion anzetteln, da gibt es genug zum Thema bereits. Fühle mich wie in einem Trabbi-Fan-Forum, wo ich erklären soll, warum ein Trabbi kein "richtiges" Auto ist.

Ganz kurz: Daß die Daten in Tabellenform abgespeichert werden, ist nur ein Teil. Was fehlt, ist der aktive Serverprozeß; es gibt kein eigenes System, das Anfragen bearbeitet.

Nimm mal eine SQL-Anfrage, die einen Join über mehrere Tabellen macht, gruppiert und mit einer Having-Bedingung auswertet, wo z. B. nur eine Zeile Ergebnis zu erwarten ist. Access ist kein Client-Server-System, wo der Server das SQL entgegennimmt, die Anfrage auswertet und die Trefferzeile zurückschickt. Es muß die ganzen Tabellen über das Netz transportieren und die Auswertung im PC machen. Beim Client-Server spielt im Beispiel die Netzbandbreite keine Rolle, wenn das Beispiel im Access Ewigkeiten dauert, heißt es hingegen immer "du brauchst eben eine schnellere Internetverbindung, das liegt nicht am Access".

Access ist im Vergleich zu einem großen RDBMS wie die kleine WG-Küche, wo jeder sich selber sein Brot schmiert und schauen muß, daß er nicht den anderen in die Quere kommt, im Vergleich zu einem Restaurant, wo es Kellner gibt, die Plätze zuweisen, Bestellungen annehmen, die Köche die Menüs zubereiten und die Kellner es dann servieren.

Im Access gibt es keine Concurrency-Control und Serialisierbarkeit, keine pessimistischen Sperren und schon gar keine Sperren auf Datensatzebene (wie soll die Backend-mdb-Datei auch wissen, welche Schreibkonflikte existieren, das ist wie in der WG-Küche, wo zwei das Kochen anfangen und erst mitten drin merken, daß die Eier für beide nicht reichen), es gibt keine Redo-Logs ("einfach öfter ne Kopie machen, gaaanz wichtig und wenn die Datenbank zerschossen ist, mit der Kopie weitermachen"). Dirty-Reads und Lost-Update kann nicht ausgeschlossen werden.

Und unter vielen Weiteren, das meinte ich eingangs und das war wohl der Aufhänger, gibt es keine Constraints oder Trigger, die die Beziehungen zwischen unterschiedlichen Feldern oder gar Tabellen prüfen. Es kann also kaum prüfen, wenn B mit A verheiratet ist, und dann bei A auch in jedem Zeitpunkt drinsteht, daß er mit B verheiratet ist (wenn ich falsch liege, lasse ich mich gern eines besseren belehren).

Access ist für echten Multiuser-Betrieb und kritische Anwendungen nicht gebaut, die Jet-Engine ist da völlig rudimentär. Das schließt nicht aus, das es nicht so la la geht. Mit einem Trabbi kannst Du auch nach Sizilien fahren, aber eigentlich ist er dafür nicht gebaut. Mit einem Trabbi kannst Du auch einen kleinen Wohnwagen ziehen, solange es nicht bergauf geht.

Im Vergleich zu welcher Entwicklungsumgebung ist Access komfortabel? Gint es Versionsvergleich, Einfügen von Codeblocks, Scrapbooks? Was ist mit Parallelität,  verteilten Anwendungen etc. ? Access ist komfortabel, weil es Laien und Hobbyprogrammierer kleine Desktopanwendungen zusammenklicken läßt und ihn nicht mit Antworten auf Fragen verwirrt, die er nie stellen würde.

Bist Du jetzt zufrieden mit der Antwort? Ich meinte urprünglich nur, daß es bei den Constraints im Access ein bißchen ärmlich zugeht.

Hallo,
ich muss zugeben, Du hast mich jetzt erschlagen. Auch ich will keine Diskussion entfachen, (und schon gar keine Hitzige), dazu fehlt mir Hintergrund was andere DB-Entwicklungssysteme betrifft. Ich hatte mich nur etwas an der pauschalen Aussage gestört dass Access keine richtige Datenbank ist. Access erhebt ja auch nicht den Anspruch hier große Datenbanken zu entwickeln zu können. Es ist ein einfaches Entwicklungssystem um kleinere bis mittlere DBs zu entwickeln die keinen größeren Anspruch auf Sicherheit (der Daten) haben.
Auch die maximale Größe ist ja auf 2GB beschränkt.

Und es dürfte unbetritten sein, dass man auch mit Access sehr sorgfältig die Struktur der DB anlegen muss um vernünftige Ergebnisse zu bekommen. Einfach zusammenklicken geht auch bei Access nicht, wenn man vernünftige Ergenisse haben will. Die Access Foren beweisen es. Und es lassen sich mit einfachen Mitteln ansprechende Bedienoberflächen gestalten.

Aber wie gesagt, ich habe absolut keine Vergleich zu andern DB Systemen. Aber ich habe auch die Erhahrung gemacht, dass viele die vorhanden Möglichkeiten von Access nicht kennen oder diese unterschätzen. Es gab hier vor kurzem eine Diskussion zu zusammengsetzten eindeutigen Indizes, die vielen nicht bekannt waren. Auch bei einem Vielantworter hier.

Kannst Du mir den Satz mal erklären, das habe ich nicht verstanden.

ZitatEs kann also kaum prüfen, wenn B mit A verheiratet ist, und dann bei A auch in jedem Zeitpunkt drinsteht, daß er mit B verheiratet ist (wenn ich falsch liege, lasse ich mich gern eines besseren belehren).

Hi,

ZitatFühle mich wie in einem Trabbi-Fan-Forum, wo ich erklären soll, warum ein Trabbi kein "richtiges" Auto ist

...und du bist also der Meinung - nur wenn ein Stern vorn drauf pickt ist's ein richtiges Auto ... :-\
Aber wenn du dich hier wie in einem Trabi-Fan Forum fühlst ... tja .... es wird ja niemand dazu gezwungen ...


Ich darf mich da vollinhaltlich der Meinung von MzKlMu anschließen - und vielleicht noch ergänzen:

ZitatWas fehlt, ist der aktive Serverprozeß; es gibt kein eigenes System, das Anfragen bearbeitet

Access erhob sei seiner ersten Version niemals den Anspruck ein DB-Server zu sein - leider geht dieses grundlegende Info wie so viele andere auch bei so manchen Kritikern nicht nur an den Augen sondern auch an anderen Stellen spurlos vorbei.

Wenn du dann noch ein Argument findest zu erklären was eine RICHTIGE Datenbank ist und dazu schlüssig rüber bringst warum Access keine Datenbank sein soll, dann könnte ich fast annehmen, dass du das Konzept von Access verstanden hast. Aus einigen deiner Argumente geht da eher das Gegenteil hervor.  >:(

ZitatNimm mal eine SQL-Anfrage, die einen Join über mehrere Tabellen macht, gruppiert und mit einer Having-Bedingung auswertet, wo z. B. nur eine Zeile Ergebnis zu erwarten ist. Access ist kein Client-Server-System, wo der Server das SQL entgegennimmt, die Anfrage auswertet und die Trefferzeile zurückschickt. Es muß die ganzen Tabellen über das Netz transportieren und die Auswertung im PC machen.

Woher hast du denn diese glorreiche Info? Irgendwie beschleicht mich der Gedanke mal 'gelesen' zu haben, dass ich mir das aussuchen kann wo was abgearbeitet wird. (CursorLocation = adUseServer ?)

ZitatEs kann also kaum prüfen, wenn B mit A verheiratet ist, und dann bei A auch in jedem Zeitpunkt drinsteht, daß er mit B verheiratet ist (wenn ich falsch liege, lasse ich mich gern eines besseren belehren)

...ES vielleicht nicht - aber ER oder SIE, der Entwickler oder die Entwicklerin - mit ein wenig rudimentärem VBA...!

und dann gäb's noch ein paar ...

Man sollte vielleicht nicht Birnem mit Äpfeld verwechseln oder gar Hunde und Katzen kreuzen wollen.

Ist aber dennoch bemerkenswert, dass du dich herabläßt und scheinbar selbst mit diesem minderwertigem Zeugs hantierst? ;)

Zitat von: MzKlMu am August 18, 2010, 20:11:41

Aber wie gesagt, ich habe absolut keine Vergleich zu andern DB Systemen. Aber ich habe auch die Erhahrung gemacht, dass viele die vorhanden Möglichkeiten von Access nicht kennen oder diese unterschätzen. Es gab hier vor kurzem eine Diskussion zu zusammengsetzten eindeutigen Indizes, die vielen nicht bekannt waren. Auch bei einem Vielantworter hier.

Hi, es freut mich, daß Du nicht gereizt reagierst und Dich angegriffen fühlst. Jeder hat einen anderen Fokus, und ich stimme Dir absolut zu, daß die Möglichkeiten von Access gewaltig sind. Ich finde es ganz schade, daß die meisten Endanwender mit riesigen Exceltapeten arbeiten und das das reinste Chaos ist (welches durch Benutzung von Access zu vermeiden wäre). Diese Excel-Jockeys kucken einen immer an wie ein U-Boot, wenn man nur die Daten an ganz wenigen Stellen anfassen muß und man mit Knopfdruck jederzeit wunderschöne Auswertungen hat, während Sie immer stundenlang dasitzen, Formate kopieren, copy and paste machen, Zwischenstand abspeichern etc. Das Geheimnis ist die Trennung von Daten und Präsentation und natürlich die normalisierte Datenhaltung mit sauberen Datentypen und referenzieller Integrität. Ich würde in einem Excelforum jederzeit Access propagieren (für Aufgaben, für die Excel einfach nicht gemacht ist), auch auf die Gefahr, daß das nicht gut ankommt.

Es hat aber natürlich einen Grund, warum Access für kritische Anwendungen nicht verwendet wird. Und wenn ich vom Oracle auf Access zurückkomme (für Sachen auf dem lokalen PC und Datenhaltung in der Arbeitsgruppe), dann fällt mir halt manchmal auf, was Access alles nicht so gut kann und erwähne das manchmal auch. Manche Cowboys scheinen sich da gekränkt zu fühlen und mich zum Duell herauszufordern.

ZitatKannst Du mir den Satz mal erklären, das habe ich nicht verstanden.
Es kann also kaum prüfen, wenn B mit A verheiratet ist, und dann bei A auch in jedem Zeitpunkt drinsteht, daß er mit B verheiratet ist (wenn ich falsch liege, lasse ich mich gern eines besseren belehren).

Access kann prüfen in einem Feld einen Fremdschlüssel, einen Bereich (Between, IN (A, B, C)), aber es kann gegen einen Wert in einer anderen Zeile prüfen. Wenn also Mann und Frau untereinander sind in zwei Tupeln, dann kann Access nicht prüfen, ob die andere Zeile dazu passt. In RDBMS gibt es dafür Trigger, die direkt auf dem Server prüfen, ob diese Bedingung erfüllt ist (und egal, was in der Anwendung codiert ist und egal, ob man man über ADO, JBDC oder welche Datenbankschnittstelle auch immer mit der Datenbank verbunden ist).

Grüße
Johannes

Zitat von: database am August 18, 2010, 21:16:18
Aber wenn du dich hier wie in einem Trabi-Fan Forum fühlst ... tja .... es wird ja niemand dazu gezwungen ...

Ich bin also blöd und soll gehen? Trabbis sind doch cool (im Vergleich zum zu Fuß gehen), aber man wird doch sagen können, daß denen ABS und Airbags und Knautschzone fehlen, ohne als Besserwessi zu gelten.

Wenn du dann noch ein Argument findest zu erklären was eine RICHTIGE Datenbank ist und dazu schlüssig rüber bringst warum Access keine Datenbank sein soll, dann könnte ich fast annehmen, dass du das Konzept von Access verstanden hast.

Anstatt vieler Worte:
http://www.bw.fh-deggendorf.de/kurse/db/skripten/skript10.doc
http://www.blume-edv.de/Resources/db_b.pdf

ZitatIrgendwie beschleicht mich der Gedanke mal 'gelesen' zu haben, dass ich mir das aussuchen kann wo was abgearbeitet wird. (CursorLocation = adUseServer ?)

Wo kein Server, da auch keine Serverlocation (soviel zu meinem Konzeptverständnis :-= ). Weißt Du auch, daß das einfach ignoriert wird?  Die Jet-Engine macht da keinen Unterschied.

ZitatEs kann also kaum prüfen, wenn B mit A verheiratet ist, und dann bei A auch in jedem Zeitpunkt drinsteht, daß er mit B verheiratet ist (wenn ich falsch liege, lasse ich mich gern eines besseren belehren...ES vielleicht nicht - aber ER oder SIE, der Entwickler oder die Entwicklerin - mit ein wenig rudimentärem VBA...

Ich schreibe "zu jedem Zeitpunkt". Der beste Entwickler auf der Welt kann nichts machen, wenn die Hardware ausfällt inmitten einer Transaktion. Dazu gibt es Redo-Logs in echten Datenbanken.

Nana, nur nicht patzig werden ...

von blöd sein habe ich nichts geschrieben - auch nicht davon das DU gehen sollst - das wollen wir hier mal in aller Form festhalten!

ZitatManche Cowboys scheinen sich da gekränkt zu fühlen und mich zum Duell herauszufordern

Nein, keine Angst und ich messe auch nicht die Länge des ...
Auch bin ich nicht beleidigt oder sonst irgendwie gekränkt oder was immer du meinst -  ich habe nur in der relativ langen Zeit schon so viele ermüdende Labereien über Access ob gut oder schlecht und pro und dann wieder kontra gehört und gelesen, dass ich es schon nicht mehr hören oder sehen kann. Das hat nichts mit DIR persönlich zu tun, es geht um die Sache als solche. Das solltest du auf jeden Fall zur Kenntnis nehmen.
Sollte meine Argumentation dazu geführt haben, dass du obige Meinung annehmen MUSSTEST, dann darf ich mich in aller Form bei dir entschuldigen - das war nicht die Absicht!

Tja und ich diskutiere auch nicht über Oracle Vorzüge gegenüber Konkurrenzprodukten und auch nicht über Access-Interna - nicht mangels Kenntnis sondern mangel Interesse aus oben genanntem Grund.

ZitatWo kein Server, da auch keine Serverlocation

... da hast du ausnahmslos recht, wenn du aber genau gelesen hast  ... CursorLocation ....  und diese serverseitig, bedeutet NICHT zwangsweise, dass Access heimlich zum DB-Server mutiert sondern vielleicht eher den Speicherort des BE - aber egal, das kann sich meinetwegen jeder gerne zurechtbiegen wie er möchte.

ZitatDazu gibt es Redo-Logs in echten Datenbanken

Ich habe ja geschrieben man möge nicht Äpfel mit Birnen verwechseln oder?
Redo-Logs also Transaktionsprotokolle sind ein wichtiger Bestandteil von Datenbankserver-Systemen - ob das eine Datenbank 'echt' macht - meinetwegen.

ZitatDer beste Entwickler auf der Welt kann nichts machen, wenn die Hardware ausfällt inmitten einer Transaktion

...und wenn du Glück hast kannst du nach Wechsel des RAID-Systems (oder welche Hardware meinst du) auf einem DB-Server die Transaktion wiederherstellen - wie gesagt wenn du Glück hast, denn Garantie gibts auch dort keine in DIESEM Fall.

Naja und dann war dann noch die Erklärung zur echten DB:
In deinen Links - vielen Dank aber ich benötige - so glaube ich - keinen Grundkurs mehr - finde ich keinen Hinweis auf die Echtheit einer Datenbank sondern die Vorteile eines RDBMS gegenüber Desktop-Datenbanken - darüber brauchen wir uns nicht zu unterhalten, das ist ja auch nicht die Argumentation gewesen sondern der Begriff der 'echten' Datenbank im Gegensatz zu einer 'unechten' ... also komm bitte ... was soll das?

Du siehst man kann jeders Thema unendlich lange und immer wieder durchkauen - diese ganze Diskutiererei bringt doch nichts!.

Hier kommen hauptsächlich Leute her, die Hilfe suchen weil sie mit Access Probleme haben und nicht deshalb, weil sie eine Alternative zu Access suchen.

Also lass uns in Frieden die Argumente niederlegen und gut OK ... weil solches HickHack nützt ja auch niemanden!

Ich werde nicht patzig, aber die kleine Spitze wollte ich Dir nicht ersparen. Es geht nicht um Produkte, sondern um Konzepte, und je mehr Konzepte man kennt, desto besser kann man ein bestimmtes Konzept einordnen. Es gibt ja die Volksweisheit "wenn das einzige Instrument, das Du kennst, ein Hammer ist, dann wird jedes Problem zum Nagel".

Man kann sich da nichts zurechtbiegen, es geht um Fakten. Bei der Cursor-Location geht es nicht sowieso um den Verarbeitungsort der Anfrage, sondern wo die Ergebnismenge verwaltet wird.

Wenn Du weiter oben triumphierend meinst, daß man durch CursorLocation = adUseServer aus einem File-Server-System ein Client-Server-System zaubern kann, dann spricht das nicht gerade für Hintergrundverständnis ("Konzept von Access verstanden"). Die Jet-Engine nimmt viele Recordset-Einstellungen entgegen ohne Fehlermeldung, ignoriert sie aber schlichtweg; das sollte man als Meister von Access einfach zumindest ahnen. Ich kann gerne noch einmal den Vergleich mit dem Trabbi strapazieren: Dadurch, daß ich in den Trabbi ein Armaturenbrett mit Turboschalter und ABS-Knopf einbaue und die Knöpfe drücke und diese leuchten, wird der Trabbi nicht schneller oder sicherer.

Bei dem Hardwareausfall meine ich sowohl den Client als auch den Server, es muß gar nicht physikalisch etwas kaputt sein, es langt ein Bluescreen im Windows (Seitenfehler o.ä.) oder wenn die Putzfrau im Serverraum einen Stecker für den Staubsauger braucht. Nett, daß Du den Begriff RAID in den Raum wirfst aber das hat hiermit nichts zu tun. Wenn Du einen lokalen PC Access laufen läßt und eine mdb auf einem tollen RAID-Serverlaufwerk, dann muß eine mit commit abgeschlossene Transaktion erst übertragen werden (die Seiten werden da synchronisiert, nicht auf Transaktionslevel) und wenn zwischen dem Commit und dem Übertragen auf den Server etwas passiert auf dem PC, ist die Transaktion unwiederbringlich verloren. Wenn der Server abstürzt, ist es das gleiche.

Die ganze Diskutiererei ist eigentlich nicht nötig, wenn man sich klar ist, daß zum Fahren zum Kiosk ein Fahrrad reicht, für den Pizzadienst im Viertel u.U. ein Trabbi, für den Urlaub mit der Familie ein Kombi und für den Umzug ein 7,5-Tonner.

Ich schreibe hier gern mal was, am liebsten sind mir ambitioniertere Themen, wo man die Client-Fähigkeiten von Access ausreizen kann. Meistens hakt es ja bei den Fragen um das Grundverständnis von relationaler Algebra, da fehlt mir auch ein bißchen die Geduld, daß muß man sich m. E. erarbeiten und sollte man nicht vorgekaut kriegen.

lass gut sein,

ich triumphiere nicht, ich meine nichts triumphierend, gar nicht -
...Putzfrauen haben im Serverraum auch nichts zu suchen, zumindest nicht bei mir...

Ich meinte als Beispiel das Plattenarray - das zählt ja wohl zur Hardware oder?

Zitatwenn man sich klar ist, daß zum Fahren zum Kiosk ein Fahrrad reicht, für den Pizzadienst im Viertel u.U. ein Trabbi, für den Urlaub mit der Familie ein Kombi und für den Umzug ein 7,5-Tonner

Ich bin mir dessen schon bewußt - nur erklärt das die Attribute 'richtig' oder 'falsch' nicht! Nach meinem Dafürhalten eher 'geeignet' oder 'nicht geeignet'
Nochmal bitte zum Verständnis - ich brauche keinen Grundkurs, auch nicht von dir, auch dann nicht wenn es gut gemeint ist.


wie ich schon gesagt habe - es bringt nichts und spart Ressourcen.
:-X

"Nochmal bitte zum Verständnis - ich brauche keinen Grundkurs, auch nicht von dir, auch dann nicht wenn es gut gemeint ist.

wie ich schon gesagt habe - es bringt nichts und spart Ressourcen."

Du meinst, das haben schon ganz andere erfolglos versucht. Na dann...

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

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.

Hallo Johannes,

ZitatEs 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.

ZitatDer 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. ;D

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

[OT]

ZitatNachdem 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?

Zitatetwa 6 Sekunden und wirkt damit etwas lahm

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

mfg
Josef

Zitat von: Josef am August 22, 2010, 11:37:17
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).

Zitat

Zitatetwa 6 Sekunden und wirkt damit etwas lahm

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

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

ZitatIch 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.

ZitatIm Einzelzugriff ist das Teil ja auch flott.

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

mfg
Josef

Zitat von: Josef am August 22, 2010, 20:28:12
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

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

Zitatdie 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

Zitat von: Josef am August 23, 2010, 00:27:01
Hast du schon einmal adUseServer statt adUseClient ausprobiert?

Ja, aber das ändert absolut nichts.

ZitatWird 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.

Zitat
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.

Zitat
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

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.

ZitatEigentlich 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.

Zitatmit 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.

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

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

mfg
Josef

Zitat von: Josef am August 23, 2010, 13:21:08
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.

ZitatJDBC 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