Office: (Office 2010) Datensatzgruppe kann nicht aktualisiert werden

schon alleine dafür bin ich dir dankbar wie Bolle *Smilie

 

Moin,

mein Tipp: Nimm DISTINCTROW raus, starte die Abfrage und schau, wie viele Sätze geliefert werden. ich möchte wetten, da kommt mehr als einer - und deshalb ist kein Update möglich.

 

Hallo Drambeldier,

dies habe ich getan.
Es ändert sich allerdings an der Anzahl der Datensätze nichts.
Mit oder Ohne, es werden jeweils 1260 Datensätze ausgegeben.

 

Hi,

ist das immer noch das Ziel? Wenn dem so ist, dann muss in der Query ein Feld enthalten sein, das diesen Datensatz eindeutig identifiziert. Wie heißt das Feld?

Hilfreich wäre ein Hardcopy des Tabellenentwurfs, besser noch ein Bild der Beziehungen.

 

Da gibt es auf der ersten Seite, da hab ich ein Bild von den Beziehungen *Smilie

 

An den Beziehungen sehe ich, dass LIEFERSCHEINE keinen eindeutigen Schlüssel hat. Muss allerdings nicht, wenn es einen eindeutigen Index aus SORT_NR und einem (oder mehreren) weiteren Feld aus LIEFERSCHEINE gibt.

Prüfen lässt sich das mit 2 Counts: Einmal die Felder, die den Schlüsselkandidaten bilden, ein zweites mit einem zusätzlichen Distinct auf diese Felder.

 

erstmal danke für deine Antwort.
Kannst du mir n bisschen helfen und sagen wie ich was machen muss. Reicht au grob. Danke *Smilie

 

Hat keiner ne Idee? *Smilie

 

Ich lese das, habe aber meine Zweifel. Eine Abfrage, in der zwei Tabellen gejoint sind, ist m.M. nach noch nie uneingeschränkt aktualisierbar gewesen, also würde man zur Sicherheit die Finger davon lassen und einen anderen Weg suchen.

Wenn ich den Fall hier richtig verstehe, würde ich die Werte nicht in die Formularfelder schreiben, sondern unmittelbar in die Tabelle, womit sie dann nach einem Requery auch im Formular ankommen.
Die einfache Tatsache, dass Tabellen Daten speichern und Formulare primär nur Daten anzeigen und man als Entwickler auch mal direkt in Tabellen schreiben kann statt über Formulare und deren Abhängigkeiten zu stolpern, kann manchen Fall vereinfachen.

Ansatz:
Code:

Im Realfall bei Kenntnis der DB könnte das auch anders aussehen. So würde ich beide zu füllenden Felder gleich in einem Atemzug versorgen.

 

Hallo,

ich würde das Thema gern wieder aufgreifen, nachdem ich nun lange Zeit eine Pause machen musste.

Warum soll die INNER JOIN Verknüpfung nicht aktualisierbar sein?

Ich wähle doch über den INNER JOIN nur einen Datensatz aus, der sich mit den Daten einer anderen Tabelle abgleicht. Diese wird doch aber nicht verändert, wenn ich nur den einen DS ändere, und dazu noch ein Feld, welches nicht im INNER JOIN verglichen wird. Oder hab ich das falsch verstanden?

Es wäre schön, wenn ihr mir weiter so helfen könntet, wie bisher.
Ich würde die Datenbank gern dieses Jahr noch abschließen *Smilie Es ist nur noch dieses eine Problem. Den Rest konnt ich alles lösen.

LG John

 

Moin,

um den Inner Join geht es nicht.

Schau Dir das Ergebnis des Inner Joins genau an und frag Dich, ob Du anhand der ausgewählten Spalten jede Zeile des Resultates eindeutig identifizieren kannst. Nur dann lässt sich darauf ein Update durchführen.

Im Zweifelsfall nimm alle Schlüsselfelder der beteiligten Tabellen mit in die Abfrage.

 

Prüfe folgende Punkte:
- Die Felder die du "joinst" müssen jeweils einen index haben.
- Die Tabellen/Abfragen die du "joinst" müssen für sich alleinstehend aktualisierbar sein.

Gruß
JPA

 

Stell Dir ein einfaches Szenario mit zwei Tabellen (A ist die 1-Seite und B ist die n-Seite) vor und nimm an, es würde im Formular funktionieren. Außer dem Schlüsselfeld existiert in jeder Tabelle noch ein Textfeld. Ich pflege jetzt einen Datensatz ein und schreibe nach A "A" und nach B "B1" und speichere. Jetzt möchte ich einen weiteren Datensatz eingeben - in A auch mit "A" aber in B mit "B2". Wenn ein Index in A das zweimalige "A" nicht verhindert, liegen jetzt in A und in B je zwei Datensätze vor. Im Sinne einer 1:n-Beziehung ist das bestimmt nicht - dort würde man wohl eher nur einen Datensatz in A und zwei jeweils damit verknüpfte Datensätze in B erwarten.

Ausnahme sind 1:1 verknüpfte Tabellen in einer Abfrage (mit Outer Join) - da ist das oben beschriebene Phönomen ja zwingend erforderlich.

 

Hallo,

ich habe gesehen, dass das Feld SORT.NR von Lieferscheine keinen PK hat.

 

Ich versuch mal die Abfrage nachzubauen