Guten Abend - ich habe eine DB gemacht die von mehreren User benutzt wird. Die Datensätze können von allen Usern über ein Formular upgedatet/geändert werden. Mir wurde schon paar mal mitgeteilt das Aenderungen (z.B. auf tickboxes) nicht immer gespeichert werden. Ich habe aber keine Ahnung warum das passiert, da ja normalerweise alle Aenderungen beim Wechseln vom Datensatz gespeichert werden. Kennt ihr das Problem ? Kann mir jemand sagen wie ich das verhindern, bzw lösen kann. Wäre eventuell the Befehlt "RunCommand acCmdSaveRecord" nach dem update eine Lösung.
Im voraus danke für Eure Hilfe.
Gruss Cédric
Hallo,
da das eine Mehrbenutzerumgebung ist, dürfte die Ursache darin liegen, dass zwei oder mehrere User denselben Datensatz gleichzeitig manipulieren wollen, was zu Sperrkonflikten führt.
Ist die DB in FE und BE aufgeteilt?
Danke für die schnell Antwort. Nein, die DB ist nicht aufgeteilt.
Ich werden die DB nicht aufteilen. Ist "acCmdSaveRecord" nach upate eine Lösung ?
Hallo Cédric,
ZitatIch werden die DB nicht aufteilen.
Dann wirst Du wohl mit Deinen Problemen leben
müssen. Es ist dann ja auch wohl so, dass alle
User auf ein und dieselbe, ungeteilte DB zugreifen.
Da kannst Du Datenkonsistenz vergessen. Ausserdem
führt das zu den unerklärlichsten Fehlern, ewig langen
Ladezeiten von Formularen und im schlimmsten Fall zu
Abstürzen.
ZitatIst "acCmdSaveRecord" nach upate eine Lösung
Update speichert ja schon, würdest Du nur den DS noch
mal speichern.
gruss ekkehard
Hallo,
ZitatIch werden die DB nicht aufteilen.
warum eine solche absolute Aussage?
In einer Mehrbenutzerumgebeung wirst Du auf Dauer um eine Aufteilung nicht herumkommen.
Und schließlich ist eine Aufteilung ein elegantes Hilfsmittel um eine DB kontinuierlich weiter zu entwickeln, ohne auf die Daten achten zu müssen.
Hallo zusammen - Danke für Euer Hilfe/Empfehlung.
Grundsätzlich hatte ich nicht vor die DB aufzuteilen, weil ich das noch mit keiner DB gemacht habe und nur selten Probleme hatte.
Aber sicherlich macht es diesmal Sinn die DB aufzuteilen. Habe dazu noch Fragen. Habe gesehen das dafür einen Wizard gibt.
1. Nehme an ich muss nicht alle Tabellen in die Backend DB aufteilen sondern nur die Tabellen die von den Usern benutzt/geändert werden?
2. Ich habe tatsächlich das Problem das ich keine Aenderungen machen kann während andere User drin sind. Wie funktioniert den das genau ? Heisst das das ich Formulare/Abfragen & Report auf der FE version aendern kann ohne das die User die DB verlassen müssen.
Im voraus danke
Cédric
Hallo Cédric,
ZitatHeisst das das ich Formulare/Abfragen & Report auf der FE version aendern kann ohne das die User die DB verlassen müssen.
Ja, aber nur Dein eigenes.
Aufteilen heisst ja auch, dass jeder User sein eigenes FE bekommt (lokal).
An Deinem FE entwickelst Du dann weiter, und wenn Du meinst, Du hast
wieder was fertig, was die anderen auch verwenden können, verteilst Du
das FE an die anderen.
Das geht auch "automatisch"; - Google mal nach "mdbLoader".
hth
gruss ekkehard
Hallo,
ich würde alle Tabellen ins Backend nehmen. Es gibt nur ein Backend. Aber jeder User kriegt auf seinen PC das Frontend. Jetzt kannst Du an Deinem Frontend munter weiter entwickeln. Wenn Du dann wieder eine neue Version hast, wird diese bei den Usern einfach ausgetauscht.
Wenn Du aber Änderungen an den Tabellen selbst machst, z.B. Felder hinzu etc. musst Du natürlich auf die Daten achten. Dann öfnest Du exclusiv das Backend änderst die Tabellen. Hier musst Du dann mit Anfüge und Aktualisierungsabfragen für die Datenübernahme sorgen. Aber dieses Problem hast Du auch bei einer unaufgeteilten DB, das hat mit Back und Frontend nichts zu tun.
OK danke.
Problem ist das nicht immer die gleichen User mit der DB arbeiten, bzw ich nicht immer weis wem die upgedatete FE-version zugespielt werden muss.
Desshalb würde es wahrscheinlich mehr Sinn machen die DB auzuteilen, aber die FE-version auf einem gemeinsamen Folder zu speichern. Das verbessert wahrscheinlich die Performance nicht, aber sollte dafür die Datenkonsistenz sicherstellen, richtig ?
Danke Cédric
Zitat von: boehnli01 am September 22, 2012, 21:54:44
Problem ist das nicht immer die gleichen User mit der DB arbeiten, bzw ich nicht immer weis wem die upgedatete FE-version zugespielt werden muss.
Das Aktualisieren kann automatisch erfolgen, siehe:
http://www.access-o-mania.de/forum/index.php?topic=8916.0
Harald
Hallo,
Zitat... aber die FE-version auf einem gemeinsamen Folder zu speichern ...
Ist in jedem Fall der richtige Weg.
Allerdings NICHT um mit diesem FE im gemeinsamen Share zu arbeiten sondern um das FE an einer zentralen Stelle zum KOPIEREN anzubieten.
Eine ev. benötigte Aktualisierung des FE könnte dann mit Hilfe jener Vorgänge gesteuert werden, die Harald in seinem Link und ff angeboten hat.
Wenn du die Benutzer weiter mit ein un dem selben FE arbeiten läßt hast du dein unrsprüngliches Problem nur aufgeteilt aber nicht behoben.
Die Probleme beginnen in dem Moment wo zwei oder mehr Benutzer die gleiche physikalische Datei öffnen.
Hi,
in dem von mir angegebenem Link ist gemeint:
Q: Quell-Laufwerk auf dem Server
Z: Ziel-Laufwerk auf dem Rechner des Benutzers
Der Benutzer holt sich vom Server die aktuelle Version und arbeitet damit auf seinem Rechner. So werden Konflikte vermieden.
Und anbei die Aussicht auf weitere "Spaßfaktoren" beim Multiuser-Betrieb: Du solltest Dir ein Sperrkonzept überlegen, wenn mehrere Benutzer denselben Datensatz bearbeiten wollen. Die Möglichkeiten von access sind nämlich suboptimal (da war das uralte dbase um Lichtjahre weiter).
Harald
Nochmals danke für die Hilfe - die Unterstützung ist wirklich genial.
Ich habe mich entschieden die User der DB registrieren zu lassen, bzw das nur noch registrierte User auf die DB zugreifen können.
Das heisst ich habe volle Kontrolle und weis auch wem ich die DB jeweils per email schicken muss. Die DB auf den gemeinsame Server
kann ich ja lassen.
Muss ich mich auf etwas spezielles achten, beim versenden der DB als attachment oder reicht drag & drop von meinem Folder ins email.
Habe nämlich auch schon festgestellt das teilweise das attachment als link verschickt wurde, aber das ist glaube ich nur bei shortcuts.
Gruss Cédric
Hallo,
ZitatMuss ich mich auf etwas spezielles achten, beim versenden der DB als attachment...
Ja, mußt du!
Die Pfade der Tabellenverknüpfungen müssen richtig angegeben sein.
Wobei sich für mich die Frage stellt, warum du die FEs per Mail verschicken willst. Liegen denn die FEs außerhalb deiner Domäne?
Wenn du dabei MS-Outlook verwendest solltest du die Dateiendung ändern - Outlook stellt eine *.mdb / *.accdb nicht so ohne Weiteres zu (Sicherheitskonzept von Outlook),
sonst kann es dann schon passieren, dass der Empfänger einen vermeintlichen 'Link' sieht aber die DB nicht bekommt..
Z.B. *. md_ oder *.accd_ - die Benutzer müssen nach dem Erhalt dann die Endung wieder auf Original zurückbenennen.
Hi,
neben dem von Peter geschilderten Nachteil beim Verschicken, hat dieses Aktualisierungsverfahren die Eigenschaften:
- bei jeder (kleinen oder größeren) Änderung gilt es, die Benutzer mit einer Email + Anhang zu informieren.
- dabei können leicht größere Datenmangen zustande kommen: wenn die Datenbank irgendwann mal 50 MB erreicht hat und sie an nur 20 Leute bei X-Änderungen verschickt wird, wird sich die IT-Abteilung über die Gigabytes an Datenverkehr freuen ;D
- Die Mitarbeiter werden auch "hoch beglückt" sein, wenn sie zumindestens anfangs womöglich mehrere Versionen in kurzer Zeit zugeschickt bekommen
- wie stellst Du sicher, dass die Mitarbeiter auch wirklich die neue Version benutzen? Bei Kleinkram-Änderungen mag es ja egal sein, wenn die mit einer alten Version arbeiten, wenn es aber Fehler gab oder im Sicherheitskonzept etwas geändert wurde, darf es keine "freiwillige" Aktion sein, auf die neue Version umzuschalten.
Bei einigen dieser Bemerkungen habe ich unter Umständen den Fehler gemacht, mein Programmierverhalten auch auf andere zu übertragen. Wenn bei Dir die Realität also ganz anders sein sollte, Asche auf mein Haupt.
Harald
Also gut - ich werde die FE-DB nicht als Attachment mitschicken, sondern die User einfach per email informieren das eine neue DB Version auf dem gemeinsamen Pfad verfügbar ist. Diese sollte dann auf den lokalen Computer kopiert werden. Bei jedem "grösserem" Update werde ich dann die User informieren dass eine neuer Version verfügbar ist die wiederum auf dem lokalen Computer kopiert werden muss. Macht das Sinn ?
Hallo Cédric,
Schau Dir dies an:
http://www.dbdev.org/down42.htm (http://www.dbdev.org/down42.htm)
hth
gruss ekkehard
Hi Ekkehard - kann es sein der MDBLoader nur mit Access2003 funktioniert (ich habe 2010) oder mache ich etwas falsch.
Hallo Cédric,
Nö, der sollte auch mit A2010 funzen.
Bei mir tut er jedenfalls. Wobei ich sagen
muss, dass ich den für meine Bedürfnisse
etwas abgespeckt habe.
Leider habe ich den auch nicht hier, nur
in der Firma. Da bin ich aber erst in 1 1/2
Wochen wieder.
Du könntest aber auch mal schreiben wo
er hakt; - Fehlermeldungen?
Antworten kann ich aber auch erst wieder
morgen Abend (mit Chance; - bin im Urlaub
und habe da jetzt nicht den ganzen Tag Zeit.
gruss ekkehard
P.S. Vielleicht kann jemand anders einspringen,
der den MBDLoader auch kennt.