none
Schreibkonflikt beim Ändern eines DS von Sql-Server View

    Frage

  • Ich habe eine Access 2010-DB auf SQL-Server umgestellt.

    Eine der zentralen Views verweist auf mehrere Tochtertabellen, u.a. 1:n der tblPatienten/tblFaelle usw.

    Den Part des Eingabeformulars, bei dem die 1:n Beziehung(en) zum Tragen kommen habe ich scheinbar im Griff.

    Ich kann den DS mit den Eingaben bis zu diesem Punkt speichern.

    Ich hatte schon zu Anfang das Schreibkonflikt-Problem, welches wohl häufiger im Zusammenhang SQL/Access auftritt und dachte, daß ich es mit timestamp-Spalten der beteiligten Tabellen im view geöst hätte, aber mitnichten:

    Rufe ich den DS jetzt auf und ergänze die Daten durch Eingabe in Felder der Tabelle "Termin", dann kriege ich wieder den Schreibkonflikt.

    Diese Tabelle ist über einen LEFT OUTER JOIN  mit der ID der tblFaelle verbunden. Ich trage schon manuell vor dem Speichern in das Verknüpfungsfeld der Tabelle "Termin" die ID aus tblFaelle ein (wird auch angezeigt). Dennoch bekomme ich den Schreibkonflikt.

    Ich habe auf jeden Fall von der Termintabelle und der Falltabelle den timestamp im view!

    Wenn ich übrigens im SSMS eine manuelle Update-Abfrage für dieses Feld mache, dann kommt keine Fehlermeldung, aber eine Meldung, daß 0 Zeilen betroffen sind.

    Gibt es einen Weg diesen Fehler zu finden?`Zugegeben die Basisabfrage ist gross und unübersichtlich

    Dienstag, 2. September 2014 16:27

Antworten

  • Hallo Nico,

    ... leider hat das nichts gebracht ist hier die falsche Antwort ;)

    Bei einer Umstellung auf eingebundene Tabellen via ODBC (SQL Server uam.) gelten neue Regeln. Davon auszugehen, dass es weiter wie mit einer Access Datenbank als Backend funktioniert trifft generell nicht zu.

    Zum einen wiederholt: SQL Server Sichten sind nicht das gleiche wie Access Abfragen.

    Komplexere Abfragen, quasi alle JOINs - spätestens aber mit LEFT/RIGHT OUTER JOINs - sind technisch gesehen nicht mehr äquivalent umzusetzen. Denn was Access bei (s)einem ISAM kann, nämlich in mehreren Tabellen rumpfuschen, geht über ODBC nicht mehr.

    Es gilt immer die Regel: Aktualisiert werden kann nur eine Tabelle und auch nur dann, wenn deren Primärschlüssel eindeutig bestimmt werden kann.

    Im allgemeinen gilt deswegen: Verwende einfache Abfragen (eine Tabelle) als Formulardatenquelle - verzichte dabei auf Sichten.

    Einfache Nachschlagefelder - vormals häufig INNER JOIN - kann man zum Teil über DLookup (und Co.) erledigen. Komplexere Abfragen bzw. mehrere Felder aus Fremdtabellen ggf. über (verknüpfte) Unterformulare - was meist auch Layoutänderungen mit sich bringt.

    Wenn möglich sollte man mit dbOpenSnapshot oder sogar mit Passthrough Abfragen arbeiten, spätestens wenn es träge wird...

    Summa Summarum wirst Du am Ende eine komplett andere Access Anwendung haben.

    Gruß Elmar

    • Als Antwort markiert NicoNi Samstag, 11. Oktober 2014 19:24
    Donnerstag, 9. Oktober 2014 10:15

Alle Antworten

  • Hi,
    ohne die Abfrage zu kennen, ist eine Problemsuche kaum möglich. Wenn es in der Abfrage Verknüpfungen gibt (JOIN), ist ein fehlerfreies Rückschreiben nicht möglich.

    --
    Peter Fleischer
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 3. September 2014 03:20
  • Ich poste später mal die JOINs. Aber JOINS sind vorhanden in Hülle und Fülle.

    Zunächst mal habe ich nur die Entgegnung auf Lager : "Aber in Access hat's doch jahrelang funktioniert"

    Daher stellt isch die grundsätzliche Frage wie man mit einer SQL-DB dieses Problem angeht.

    Ich habe in grauer Vorzeit die Aufteilung in 2 tabellen "Faelle" und "Termine" vorgenommen, da nicht zu jedem Fall ein termin existieren muss.

    Für DIESEN Zweck könnte ich mir 2 Lösungen vorstellen:

    1. Entfernen der Term,in-Tabelle aus dem View und Nutzung eines UFormulars für den Termin.

    - wie verhindere ich dann, daß MEHRERE Termine angelegt werden

    2. Alternativ komplett separates Formular

    3. Verzicht auf die separate Tabelle Termine und Verlagerung der Felder in die Falltabelle.

    -Dürfte eher aufwändig sein

    Und das grundsätzliche Problem ist damit noch nicht gelöst

    Mittwoch, 3. September 2014 07:15
  • Hallo Nico,

    nur weil etwas mit einer Access Datenbank funktioniert heißt das nicht, dass es mit einer ODBC Datenquelle funktioniert. Das fängt schon damit an, dass Access gar keine Sichten kennt, sondern nur Abfragen (womit Dein Argument keines ist).

    Es gelten hier die Regeln für Sichten wie bei CREATE VIEW unter "Aktualisierbare Sichten" beschrieben.

    Hinzukommt dann die Access Logik, die sich anhand der Basis Tabelle den Primärschlüssel ermittelt um die Aktualisierung durchzuführen.

    Im allgemeinen sollte man via ODBC nur eine Tabelle je (Unter-)Formular haben, die man aktualisiert.

    Zu den Ansätzen wäre 1. durchaus machbar:

    Die "Termine" könnten in ein Unterformular gelegt werden. Wenn die Termin Tabelle neben ihrem  Primärschlüssel (ID) den Schlüssel der "Faelle" als eindeutigen Schlüssel hat, so wäre nur ein Termin möglich. Soll es nur ein Termin pro Datum sei, erweitere den eindeutigen Schlüssel um das Datum.

    Gruß Elmar

    Mittwoch, 3. September 2014 08:53
  • Sorry,  daß ich nicht geantwortet habe.

    Der Verweis auf den Artikel aktualisierbare Sichten habe ich schon mehrfach gefunden, leider hat mir das nichts gebracht.

    Die Variante mit dem unterformular muss erstmal umgesetzt werden. leider hängt von der bisherigen Access-Version sehr viel Code dran, der dann auch nicht mehr funktioniert.

    Leider hat die idee die bestehende DB auf SQL mit Access-Frontend vieles kaputt gemacht, was aktuell shr viel Basteleien verursacht. zum Glück muss die DB nur von mir und der Sekretärin bedient werden.

    Donnerstag, 9. Oktober 2014 08:14
  • Hallo Nico,

    ... leider hat das nichts gebracht ist hier die falsche Antwort ;)

    Bei einer Umstellung auf eingebundene Tabellen via ODBC (SQL Server uam.) gelten neue Regeln. Davon auszugehen, dass es weiter wie mit einer Access Datenbank als Backend funktioniert trifft generell nicht zu.

    Zum einen wiederholt: SQL Server Sichten sind nicht das gleiche wie Access Abfragen.

    Komplexere Abfragen, quasi alle JOINs - spätestens aber mit LEFT/RIGHT OUTER JOINs - sind technisch gesehen nicht mehr äquivalent umzusetzen. Denn was Access bei (s)einem ISAM kann, nämlich in mehreren Tabellen rumpfuschen, geht über ODBC nicht mehr.

    Es gilt immer die Regel: Aktualisiert werden kann nur eine Tabelle und auch nur dann, wenn deren Primärschlüssel eindeutig bestimmt werden kann.

    Im allgemeinen gilt deswegen: Verwende einfache Abfragen (eine Tabelle) als Formulardatenquelle - verzichte dabei auf Sichten.

    Einfache Nachschlagefelder - vormals häufig INNER JOIN - kann man zum Teil über DLookup (und Co.) erledigen. Komplexere Abfragen bzw. mehrere Felder aus Fremdtabellen ggf. über (verknüpfte) Unterformulare - was meist auch Layoutänderungen mit sich bringt.

    Wenn möglich sollte man mit dbOpenSnapshot oder sogar mit Passthrough Abfragen arbeiten, spätestens wenn es träge wird...

    Summa Summarum wirst Du am Ende eine komplett andere Access Anwendung haben.

    Gruß Elmar

    • Als Antwort markiert NicoNi Samstag, 11. Oktober 2014 19:24
    Donnerstag, 9. Oktober 2014 10:15