Office: (Office 2010) Abfrage

Hi,

ich habe eine Frage zum Öffnen einer Abfrage.

Meine Abfrage hat 5 n:n Verbindungen. Zwei zu anderen Abfragen und drei zu Tabellen.

In der Mitte steht eine Tabelle, und diese 5 Verbindungen sind die Lookup-Tabellen mit den Werten. In der Haupttabelle stehen nur ID’s und ich hole mir dann die Bezeichnungen.

Leider bekomme ich beim Öffnen links unten im roten Bereich die Aussage „Dieser Recordset kann nicht aktualisiert werden“

Nun habe ich zwei Fragen. Gibt es die Möglichkeit rauszufinden, welcher Recordset das ist und/oder wo das Problem liegt.

Habe schon ein bisschen was gelesen, da war von zu vielen Verknüpfungen die Rede aber nur 1:n und n:1. Diese habe ich ja nicht.

Habe versucht einzelne Tabellen abzukoppeln und so den Fehler zu finden, aber ohne Erfolg. Konnte kein Muster ausmachen.

HOFFENTLICH KANN MIR EINER HELFEN. Wenn ich die Abfrage öffne geht es noch mit der Geschwindigkeit, aber wenn ich die Abfrage filtere wird sie sehr langsam!

:)

 

Kannst Du die Abfrage bzw. deren SQL-Anweisung zeigen?
Ich vermute hier wird durch die diversen JOINS eine nicht aktualisierbare Abfrage entstehen.

Wieso willst Du überhaupt direkt in der Abfrage editieren?
Datenerfassung/manipulation sollte i.d.R. über Formulare erfolgen. Die geschilderten Daten deuten hier dann auf eine Konstruktion mit (mehreren) Unterformularen hin.

 

Die Eingabe ist in einem Formular. Da habe ich das Problem auch und habe nach der Lösung gesuch. Dann habe ich festgestellt, dass es auch schon auftritt wenn ich nur die Abfrage ausführe.

Muss die SQL leider etwas abspecken. Kann nicht die genauen Bezeichnungen nehmen. Hoffe es hilft trotzdem.

Hier die Struktur:

SELECT TABELLE1.ID, TABELLE1.DATUM AS Datum, TABELLE2.BEZEICHNUNG AS Status, TABELLE3.BEZEICHNUNG AS Medium, TABELLE1.ZUSATZINFO, TABELLE1.BETRAG_PLAN, TABELLE1.BETRAG_BEZAHLT, TABELLE1.LAND_ID, TABELLE1.STATUS_ID, TABELLE3.BEZEICHNUNG, Abfrage1. BEZEICHNUNG, TABELLE1.INSERATGROESSE_DETAILS, TABELLE1.ANHANG_LINK AS Link, TABELLE1. PREIS, Abfrage2.JAHR,
FROM Abfrage2 INNER JOIN (TABELLE3 INNER JOIN (TABELLE2 INNER JOIN (TABELLE3 INNER JOIN (Abfrage1 INNER JOIN TABELLE1 ON Abfrage1.ID = TABELLE1.bID) ON TABELLE3.ID = TABELLE1. aID) ON TABELLE2.ID = TABELLE1.STATUS_ID) ON TABELLE3.Kurz = TABELLE1.cID) ON Abfrage2.ID = TABELLE1.WERBETYP_DETAIL_ID
WHERE (((TABELLE3.USer)=1));


Was kann ich machen um das Problem zu lösen? Zwei Abfragen?

 

Was spricht gegen die bereits vorgeschlagene Konstruktion Form->Unterform?
m.E. wirst Du über die vorliegenden JOINs keine Aktualisierung hinbekommen.

 

Ich habe ein Form und Unterform. Wenn ich das öffne kommt es halt zu langen Wartezeiten. Vor allem wenn ich gefiltert öffne. Würde gerne die Performance verbessern.

Hast du einen Vorschlag für mich? Ändere gerne meien Abfrage.

 

Geht es jetzt um Performance oder darum dass die Daten nicht aktualisierbar sind?
Zum Thema Performance und wie diese beeinflusst/optimiert werden kann gibt es hier Forum zig Beiträge...

 

Apropos:

Ein Recordset umfasst die gesamte Datenmenge, welche die Abfrage liefert, und ist nicht gleichzusetzen mit einem einzelnen Datensatz.

Eine Abfrage, die auf drei Tabellen und zwei Abfragen basiert, ist mit ziemlicher Sicherheit nicht änderbar. Für eine genauere "Diagnose" müssten alle Details bekannt sein. Sicherlich ist eine Umgestaltung des Formulars hier ein Schritt in die richtige Richtung.

 

Das aktualisieren geht. Schreibe dann direkt durch in die Zentrale Tabelle.

Ok, dann ist mein Verständnis falsch. Ich dachte es wäre wie eine Fehlermedlung zu verstehen. Als ob die Abfrage versucht was zu finden und deswegen so lange braucht.
Kann ich es nur als Infomation verstehen die meine Öffnung nicht verlangsamt?

Immer wenn das steht, zappeln einige Datebsätze und Zeilen alsob was gesucht wird.

Hatte dieses halt zurückverfolgt zur Abfrage. Aber wenn dies nicht das Problem ist, was könnte es sein?

 

Hi,

die Ursachen für das Verhalten sind in den Abfragen und evtl. auch Tabellen zu finden.
Aber mAn macht es wirklich keinen Sinn über etwas zu reden, was man nicht kennt.

Wieso n:n? Die Verknüpfung von Fremdschlüsseln zu Lookup-Tabellen erfolgt üblicherweise über eine n:1 bzw. 1:n-Beziehung.

 

Moin,

das Muster ist ganz einfach: Du versuchst ein Feld einer Tabelle zu ändern, deren Schlüssel Du nicht im Zugriff hast. Viel Spaß beim Suchen - dass Deine View eine Missgeburt ist, hat man Dir ja beim letzten Mal schon gezeigt.

Zu dem "abgespeckten" Tabellenaufbau: Ich schraube nur am Original - Inhalte sind beliebig, Struktur muss stimmen.

Gruß
Ralf

 

Moin,

das Muster ist ganz einfach: Du versuchst ein Feld einer Tabelle zu ändern, deren Schlüssel Du nicht im Zugriff hast. Viel Spaß beim Suchen - dass Deine View eine Missgeburt ist, hat man Dir ja beim letzten Mal schon gezeigt.

Zu dem "abgespeckten" Tabellenaufbau: Ich schraube nur am Original - Inhalte sind beliebig, Struktur muss stimmen.

Kann nicht sein. Eine simple Abfrage kann den Fehler nicht auslösen.

Gruß
Ralf

 

Vielen Dank für die Antworten.

Habe mich also noch weiter auf die Suche begeben und festgestellt, dass die Abfrage wohl nicht das Problem (Hauptproblem) ist. Die ist "relative" schnell.

Beim Öffnen will ich ganz am Schluß den Datensatz mit einer bestimmten ID makieren. Nach langem suchen bin ich drauf gekommen, dass der das blinken und die lange Ladezeit verursacht.

Arbeite da mit (ID ist ein string):


Code:

Gibt es da ne bessere Methode?

 

Hallo,
was bezweckst du mit dem gezeigten "Phantasie"-Code?

Wenn er Wunschdenken entspringt, solltest du das gleich dazu sagen, andernfalls könnte man annehmen, dass du das für einen funktionierenden Code hältst.
Dagegen spricht aber

1. Wenn ein Recordset eine "SetFokus"-Methode hätte, so würde sie mit Sicherheit mit "c" geschrieben - hat er aber nicht!
2. Wenn ID ein String ist, so sollten Hochkommata zum Einsatz kommen.

Und was das betrifft:

so zeige doch bitte den VBA-Code dazu, damit man sich ein eigenes Bild machen kann.