Hallo zusammen,
folgendes Problem:
Ich habe in einer Anwendung Frontend (mde) sowie Backend getrennt. Sobald ich eine gewisse Abfrage starte (also das Formular mit dieser Abfrage als Unterformular öffne) erstellt sich eine *.ldb vom Backend. Blöderweise kann niemand in die DB schreiben, solange diese *.ldb existiert (Fehlermeldung: DB ist schreibgeschützt).
Das von mir geöffnete Formular dient jedoch nur zur Anzeige von Daten, nicht zum Schreiben, so dass die *.ldb nach dem Aufbau des Fensters theoretisch überflüssig wäre.
Kann man diesen Konflikt elegant lösen? Ist das ein Grundsätzliches "Problem" oder muss ich meine Abfrage oder ggf. Schreibroutine ändern?
Hallo,
sobald eine DB geöffnet wird, wird eine ldb erstellt das kannst Du nicht verhindern. Das Sperren hat auch mit der ldb nichts zu tun. Das hat eine andere Ursache.
Auch in einer Mehrbenutzerumgebeung gibt es immer eine ldb.
Hallo,
Zitat... erstellt sich eine *.ldb vom Backend...
Das ist normal und nicht weiter besorgniserregend.
Ich vermute, dass die Berechtigungen am Serververzeichnis nicht ausreichen um in die Datenbank zu schreiben.
Kontrolliere einmal die NTFS Berechtigungen für das Laufwerk bzw. Verzeichnis in dem das BE liegt und erteile ggf. den zugreifenden Benutzern/Benutzergruppe - anfangs testweise für dich selbst - 'Ändern-Recht'
Die NTFS Berechtigungen sind soweit ok. Jeder hat gleiche Lese- und Schreibberechtigungen auf das Netzlaufwerk bzw. es wurden sämtliche User in die gleiche Gruppe gepackt.
Das Problem tritt nur dann auf, wenn eine gewisse Abfrage (qryStationsliste) bei irgend einem user offen bleibt
Dim strArtikelnummer As String
Dim strSQL As String
On Error GoTo Err_lstResult_DblClick
strArtikelnummer = lstResult.Value
strSQL = "SELECT tblTrack.trkAuftragsnummer AS Auftragsnummer, " & _
"tblUser.usrVorname & ' ' & tblUser.usrNachname AS Name, " & _
"tblTrack.trkZeit AS Zeitstempel, " & _
"tblAbteilungen.abtName AS Zielabteilung " & _
"FROM tblUser " & _
"INNER JOIN (tblAbteilungen " & _
"INNER JOIN tblTrack " & _
"ON tblAbteilungen.abtID=tblTrack.trkZiel) " & _
"ON tblUser.usr422Name=tblTrack.trkAbsender " & _
"WHERE ((tblTrack.trkAuftragsnummer) Like '" & strArtikelnummer & "') " & _
"ORDER BY tblTrack.trkZeit;"
CurrentDb.QueryDefs!qryStationsliste.SQL = strSQL
DoCmd.OpenForm "frmStationsliste"
Sobald ich das Formular "frmStationsliste" mit der Abfrage schließe ist wieder alles ok und die anderen User können wieder auf die Abfrage zugreifen bzw. in die DB speichern.
Hi,
Die Datenherkunft für dieses Formular ist eine Abfrage mit mehreren beteiligten Tabellen - das kannst du nicht reinschreiben.
Zitat von: database am August 17, 2012, 10:35:50
Hi,
Die Datenherkunft für dieses Formular ist eine Abfrage mit mehreren beteiligten Tabellen - das kannst du nicht reinschreiben.
Ich will ja nicht über diese Abfrage schreiben, sondern nur lesen. Schreiben möchte ich nur in die "tblTrack", was aber nicht geht wenn jemand anderes das og. Formular geöffnet hat.
Es ist sogar so, dass das o.g. Formular nicht mal von zwei usern gleichzeitig angezeigt werden kann. Der Zweite bekommt eine leere Abfragetabelle
Hallo,
ZitatSchreiben möchte ich nur in die "tblTrack", was aber nicht geht
Das wird davon herrühren, dass die tblTrack Bestandteil des Recordsets ist und so eine Sperre erfährt.
ZitatEs ist sogar so, dass das o.g. Formular nicht mal von zwei usern gleichzeitig angezeigt werden kann. Der Zweite bekommt eine leere Abfragetabelle
Erstelle die Abfrage und binde sie ins Frontend ein.
Vorausgesetzt, dass jeder Benutzer eine Kopie des FE auf seinem Rechner hat.
Zitat von: database am August 17, 2012, 10:59:59
...Das könntest du umgehen, wenn du die Abfrage nicht zur Laufzeit erstellst sondern diese unter ihrem Namen fix einbindest.
Das geht leider nicht, da die Abfrage abhängig von zur Laufzeit ermittelten Werten ist. Mit diesem Problem könnte ich ja auch noch leben.
Zitat von: database am August 17, 2012, 10:59:59
...Das wird davon herrühren, dass die tblTrack Bestandteil des Recordsets ist und so eine Sperre erfährt...
Das ist der Knackpunkt. Kann ich das irgendwie umgehen? Ich meine, zum Lesen müsste theoretisch ja keine Sperre erstellt werden. Oder denke ich da zu einfach?
Hmmm...
ZitatDas geht leider nicht, da die Abfrage abhängig von zur Laufzeit ermittelten Werten ist
Du kannst doch in der fixierten Abfrage ebenfalls Feldverweise unterbringen.
ZitatKann ich das irgendwie umgehen?
EINE Möglichkeit wäre, statt der Abfrage eine temporäre Tabelle im FE zu erstellen, die beim Öffnen des Formulars erzeugt und beim Schließen wieder gelöscht wird.
Diese Tabelle bestimmst du dann als Datenherkunft für das Formular.
Ok, danke erst mal, ich werde sehen ob ich das realisieren werde oder mit dem "Fehler" lebe.
Was ich nicht verstehe, ist folgendes:
Die Access-Einstellungen
- Standardöffnungsmodus: Freigegeben
- Standard bei Datensatzsperrung: Bearbeiteter Datensatz
- DB mit Sperrung auf Datensatzebene öffnen: ist angeklickt
wurde nicht überschrieben.
Microsoft sagt dazu:
ZitatSperrung auf Datensatzebene In Access wird nur der bearbeitete Datensatz gesperrt. Andere Datensätze sind nicht betroffen.
Da ich aber keinen neuen Datensatz zu "tblTrack" hinzufügen kann stimmt doch diese Aussage nicht, oder?
Zitat von: database am August 17, 2012, 11:20:54
Ich meine, zum Lesen müsste theoretisch ja keine Sperre erstellt werden. Oder denke ich da zu einfach?
Das wundert mich sehr, daß beim Lesen eine Sperre gesetzt werden soll. Im Access-Umfeld habe ich das noch nie gesehen oder gehört (es gibt in anderen Plattform das SELECT FOR UPDATE, aber bei solchen JOIN-Abfragen ginge das sowieso nicht). Jet (das Access-Datenbanksystem) sperrt sowieso immer optimistisch, d.h. erst beim Schreiben wird evtl ein Fehler gemeldet. Mit Backend-Frontend Anwendungen hatte ich eigentlich nie Sperr-Probleme, allerdings habe ich ADO statt DAO verwendet, das dürfte aber absolut keinen Unterschied in Bezug auf das Problem machen.
Das naheliegendste wäre, zu prüfen, ob im Backend der Flag für den exklusiven Zugriff gesetzt ist. Die ldb-Datei führt die momentan angemeldeten User, aber wie bereits gesagt, führt die Existenz dieser Datei allein zu keinen Sperren.
Zitat von: Wurliwurm am August 17, 2012, 11:41:13
...Das naheliegendste wäre, zu prüfen, ob im Backend der Flag für den exklusiven Zugriff gesetzt ist. ..
Wie prüfe ich das?
Kannst Du mal in die Optionen von Access gehen und sagen, wie es eingestellt ist
Ein Screenshot anbei, aus Access 2010.
[Anhang gelöscht durch Administrator]
Hallo,
ZitatDa ich aber keinen neuen Datensatz zu "tblTrack" hinzufügen kann stimmt doch diese Aussage nicht, oder?
Wenn die generellen Einstellungen der Abbildung entsprechen können mehrere Benutzer Daten in ein und die selbe Tabelle schreiben.
Verhindert wird es nur dann, wenn wie angegeben der gleiche Datensatz betroffen ist.
In deinem Fall wird die Sperre wahrscheinlich verhängt weil die Tabelle an anderer Stelle an einem nicht aktualisierbaren Recordset beteiligt ist.
Zitat von: database am August 17, 2012, 12:44:31
...In deinem Fall wird die Sperre wahrscheinlich verhängt weil die Tabelle an anderer Stelle an einem nicht aktualisierbaren Recordset beteiligt ist.
Mir ist nur nicht klar, wo. Der Quellcode beschränkt sich auf das oben gepostete (Fehlerbehandlung mal ausgeschlossen). Auch in dem sich öffnenden Fenster ist kein "form.open"-code o.ä. und keine anderen Elemente. Nur ein "close"-button und ein button um einen Bericht mit der selben Abfrage zu öffnen.
Die Einstellungen sehen bei mir wie folgt aus:
[Anhang gelöscht durch Administrator]
In diesem Forum ist eine andere Möglichkeit beschrieben:
http://www.wiredbox.net/forum/Thread406980_The_Parameter_is_incorrect_error_message.aspx
ZitatI see a solution by a Citrix support person:
"I think this bad behaviour comes from the (domain) group policy.
Try to remove the MDB file type from designated file types within:
MMC -> add-snapin: GPO Editor (load your local GPO or Domain GPO)
check the settings
"Computer Configuration"
L___Windows Settings
L___Security Settings
L___Software Restriction Policies
L___Designated File Types
and remove the MDB entry."
Leider ohne Feedback. Wie seht Ihr dieses?
Hallo,
ZitatMir ist nur nicht klar, wo. Der Quellcode beschränkt sich auf das oben gepostete
Na ja eben deswegen ...
du 'erzeugst' da per Code eine Abfrage, die auch die tblTrack beinhaltet und im Anschluß daran als Datenherkunft für dein zu öffnendes Formular dient.
Somit ist die Tabelle tblTrack in Verwendung und ich vermute mal wegen der Beteiligung an einem/diesem nicht aktualisierbaren Recordset gesperrt, wenn ein anderer Benutzer aus einem anderen Formular auf die tblTrack schreibend zugreifen will.
Versuch doch einmal eine ganz einfache Abfrage als Datenherkunft wie im Code zu erstellen - ohne die tblTrack und nur zum Testen (nimm die Joins einfach mal raus).
Rufe dann das betreffende Formular auf und versuche dann von einem anderen Arbeitsplatz aus in die tblTrack zu schreiben - wenn das geht stimmt meine obige Vermutung.
Hast schon versucht wie ich angegeben habe die temp. Tabelle zu erstellen - was passiert dabei?
Vielen Dank für die Anregungen,
ich werde in den nächsten Tagen die Vorschläge testen, leider klappt das nicht zeitnah. Zu gegebener Zeit werde ich ein Feedback posten