Backend schreibgeschützt bei Abfrage

[C4RL0]

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?

[MzKlMu]

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.

[database]

Hallo,

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

[C4RL0]

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

Code [Auswählen] Erweitern

   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.

[database]

Hi,

Die Datenherkunft für dieses Formular ist eine Abfrage mit mehreren beteiligten Tabellen - das kannst du nicht reinschreiben.

[C4RL0]

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

[database]

Hallo,

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

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

[C4RL0]

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

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

[database]

Hmmm...

Das geht leider nicht, da die Abfrage abhängig von zur Laufzeit ermittelten Werten ist

Du kannst doch in der fixierten Abfrage ebenfalls Feldverweise unterbringen.

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

[C4RL0]

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:

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

[Wurliwurm]

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.

[C4RL0]

...Das naheliegendste wäre, zu prüfen, ob im Backend der Flag für den exklusiven Zugriff gesetzt ist. ..

Wie prüfe ich das?

[Wurliwurm]

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]

[database]

Hallo,

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

[C4RL0]

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