Office: (Office 2010) Nach Abfrage selektierte Datensätze für weitere Abfrage deaktivieren

Hallo zusammen,

folgende Datenfelder liegen in der Tabelle vor.

Wert1
Wert2
Felddatentyp ja/nein
Erfassungsdatum

Wenn nun eine Tabellenerstellungsabfrage (z. B. Selektiere alle Datensätze mit Felddatentyp nein) gestartet wird und die nun selektierten Daten in Excel übertragen werden. Wie kann ich anschließend, diese soeben selektierten Datensätze in Access deaktivieren, so dass diese bei einer weiteren Abfrage nicht mehr berücksichtigt werden. Bei den soeben selektierten Datensätzen müsste der Felddatentyp auf ja gestellt werden. Diesen Vorgang habe ich vor Jahren in Access 2000 während meiner Ausbildung durchgeführt. Weiß jedoch nicht mehr wie das noch funktioniert. Irgendwas war dort mit dem Button Ausrufezeichen. Könnt ihr mir den Vorgang erklären?

:)

 

Code:

Diese Anweisung muss nach dem Export ausgeführt werden.
Wie managst Du den Export?

 

Ohne Deine Abfrage gesehen zu haben:
Das machst Du mit einer Aktualisierungs-Abfrage, mit der Du ein/das Feld auf ja oder nein setzt. Bei der Erstellungsabfrage wird diese Spalte dann mit ausgelesen/gefiltert (WHERE-Klausel).

 

Hans-Christian ist auch noch wach und schneller... :-)

 

Statt eines Boolean-Feldes könnte man auch ein DateTime-Feld einsetzen, in das man den Exportzeitpunkzt setzt. Dann hätte man nicht nur die Aussage, ob, sondern auch, wann.

 

Hallo,
das Datumsfeld gibt es ja schon und kann als Kriterium dienen mit dem sich die Datensätze bestimmten Datumsbereichen zuordnen und damit einschränken lassen. Ein Ja/Nein Feld braucht es da nicht. Und eine Tabellenerstellungsabfrage auch nicht.
Der gewünschte Bereich kann über eine Auswahlabfrage jederzeit dargestellt und nach Excel exportiert werden. Sonst braucht es nichts.

 

\@gpswanderer:
Man weiss aber nicht, wann der Export immer stattfindet. Das bestehende Erfassungsdatum ist dabei ja irrelevant.
Von daher finde ich die Idee von Eberhard optimal.

 

Hallo, also ich erstelle eine Tabellenerstellungsabfrage. "Zeige mir alle Datensätze, die im Feldatentyp auf nein stehen".

Danach über die soeben selektierten Datensätze eine Aktualisierungsabfrage starten. Kriterium auf nein, Aktualisierung auf ja stellen.

Sitz gerade nicht vorm Rechner, aber ist doch theoretisch so richtig?

Falls ja, habe ich noch Fragen, die ich gesondert stelle.

 

Es ist möglich.

(Und bleibe standhaft und ignoriere zusätzliche Hinweise.)

 

Hallo!

Nur eine Anmerkung am Rande:
Die oben beschriebenen Varianten funktionieren meiner Meinung nach nicht (zu 100% sicher) in einer Mehrbenutzerumgebung, falls ein Datensatz nur einmal exportiert werden darf.

In einer Mehrbenutzerumgebung könnte ich mir folgende Vorgehensweise vorstellen:
1. Ausgewählte Daten werden in eine Protokoll-Tabelle eingefügt (für den Transfer markiert).
Tabellenaufbau:
- ID (FK zur Basistabelle) = PK damit DS nur 1x eingefügt werden kann
- TransferID (eine eindeutige Kennung für jede laufende Anwendungs-Instanz - z. B. Guid, die im Client vergeben wird. - Könnte z. B. der PK aus einer Tabelle sein, in der man einträgt, wer und wann mit dieser Transfer-Kennung einen Transfer durchgeführt hat.)

2. Nach dem Einfügen in diese Tabelle werden die DS über inner Join für den Export bereitgestellt.

3. (optional) Tranfer-Ende wird protokolliert.


mfg
Josef

 

\@Josef: heisst Abfrage mit anschließender Aktualisierungsabfrage ist nicht sicher?
@Ebethard: wenn du mir deinen zusätzlichen Hinweis "Date/Time" genauer erklärst, nehme ich den Tipp gerne an

 

Meiner Meinung nach musst du sicherstellen, dass die identischen Datensätze in beiden Abfrage-Ausführungen betroffen sind und diese auch nur von einem User verwendet wurden.

Wenn nur ein User den Export durchführt, wird das Setzen eines Datumswertes in der Basistabelle ausreichen.
Dann würde ich aber zuerst die Update-Anweisung in der Basistabelle durchführen und dann mit dem jeweiligen Datumswert die Export-Daten herausfiltern.

Der umgekehrte Weg (zuerst exportieren und dann den Export markieren) kann schief gehen, wenn in der Zwischenzeit ein anderer User einen Datensatz einfügt, der in den Auswahlfilter für den Export passt.

Ein ganz einfaches Beispiel:
Angenommen du exportierst immer alle Datensätze die noch nicht als exportiert markiert sind.
Code:

danach schreibst du die Exportkennung
Code:

Wenn jetzt ein andere User einen Datensatz nach deiner Insert-Anweisung aber vor deiner Update-Anweisung einfügte, wurde dieser DS nicht exportiert, aber als exportiert markiert.


Der meiner Meinung nach bessere Weg (nur Symbolcode!):
1. ClientTranferGuid = NewGiud()
2. Update Basistabelle set TranferGuid = ClientTranferGuid where TranferGuid is null
3. insert into Transfertabelle (Feld1, ...) select Feld1, ... from Basistabelle where TranferGuid = ClientTranferGuid

mfg
Josef

 

\@Josef: Soweit habe ich noch nicht gedacht. Weiß aber mit meinen Grundkenntnissen noch nicht wie und wo dein Beispielcode eingetragen werden muss. Aber vereinfacht gesagt, müsste ich zuerst eine Aktualisierungsabfrage starten, um den Feldatentyp vom Standardwert "nein" auf "ja" zu stellen und als zweiten Schritt dann die eigentliche Abfrage starten. "Nenne mir nun alle Datensätze, bei denen der Wert auf " ja" steht. Dann dürfte das Problem eines zwischenzeitlichen erfassten Datensatzes nicht auftreten. Richtig? Kanns leider noch nicht am Rechner testen.

 

*push*

Kann mir nochmal jemand Josefs Ansatz erklären. Geht das nur über SQL oder auch über die normale Abfrage? Er hat Recht, wenn zwischen der Abfrage und Aktualisierungsabfrage ein Datensatz eingegeben wird, dann wird dieser als exportiert markiert, obwohl er es nicht ist.

 

Statt des Ja-/Nein-Feldes (Boolean) wäre ein Datums-/Zeit-Feld zu verwenden, wohinein man den Zeitpunkt des Exports (=> Now()) schreibt.
Damit lässt sich dann auch später noch auswerten, wann ein Datensatz exportiert wurde. Das ist qualitativ eine bessere Aussage als nur, ob der Datensatz exportiert wurde, vor allem dann, wenn die Datenbank etwas länger läuft und umfangreicher wird und man dann auch mal so etwas Statistik betreiben wollte.

Mit dem Tausch der Abfragen hast Du recht. Erst die erfassten Datensätze eindeutig markieren, dann die markierten Datensätze exportieren.
Mit dem Ja-/Nein-Feld fällst Du hier auf die Nase, weil ja die vorher exportierten Datensätze auch schon auf True stehen würden.
Eine qualifiziertere Markierung ist da schon notwendig.

Code:

Was ist nach Deiner Definition eine normale Abfrage?