Office: (Office 2016) VBA: Abfrage, ob Daten in Tabelle vorhanden. Alternative gesucht

Hallo Forum!

ich habe in Access 2016 mit VBA eine Importroutine programmiert, die alle csv-Dateien (Rechnungsdaten) eines Ordners in eine Tabelle in einer Datenbank importieren soll.

Damit nichts doppelt importiert wird habe ich eine Abfrage eingebaut, die prüft, ob das zu importierende Rechnungsdatum bereits importiert wurde.

Dies realisiere ich derzeit so:
Code:

Die Variable "Prüfdatum" enthält das Rechnungsdatum der zu importierenden csv-Dateien.
Wenn Zeilen > 0, dann wird der Import abgebrochen.

Nun dauert diese Abfrage recht lange (Tabelle hat über 300.000 Einträge).

Daher habe ich versucht dies alternativ mit "FindFirst" zu lösen, was meiner Beobachtung nach aber keine spürbare Beschleunigung bringt.

Nun meine Frage:
Fällt euch vielleicht noch eine dritte Möglichkeit ein, eine solche Abfrage flotter zu gestalten?

:)

 

Hallo,
wenn auf das Rechnungsdatum ein eindeutiger Index gelegt wird, kannst du Dir die Prüfung ersatzlos sparen.
Könnte bei der Anzahl der DS eine einfache Lösung sein.

Bei Deiner Version, solltest Du prüfen, ob das Rechnungsdatum überhaupt indiziert ist. Wenn nicht nachholen und dann noch mal die Laufzeit prüfen.

Ich glaube auch nicht, dass der Vergleich des Datums stimmt. Datumsangaben müssen entweder in US Format (mm/dd/yyyy) oder im ISO Format (yyyy/mm/dd) verglichen werden.
Siehe hierzu:
FQA 6.8 Datum übergeben

 

Oh man - darauf hätte ich selbst kommen können. *Smilie
Ich kann zwar in der Tabelle keinen eindeutigen Index aber einen mit Duplikaten legen.
Diese Tabelle enthält streng genommen keine Rechnungen sondern alle Rechnungspositionen aller Rechnungen. Demnach kann ich das Datum nicht auf "eindeutig" oder "ohne Duplikat" setzen.

In dem Fall kann ich Entwarnung geben, da ich es getestet habe, ob die Routine funktioniert.
In der Tat ist mir bei SQL-Abfragen (hier beim Testen einer DB2-Datenbank) aufgefallen, dass das Datum so angegeben werden muss, wie Du es beschrieben hat.
Da es Access-intern aber auch so funktioniert. Lasse ich es erst mal so stehen.

Danke für den Hinweis auf den Index. Werde ich beim nächsten Import testen.


Siehe hierzu:
FQA 6.8 Datum übergeben[/quote]

 

Hallo,

das glaube ich eher nicht. Das solltest Du mal genauer prüfen, es wird ja kein Fehler ausgegeben, das Datum wird nur falsch interpretiert.
Aus Deutsch 12.05.2019 wird auf 05.12.2019 geprüft.

 

Grundlagen - SQL ist leicht (4) - Aktualisierung einer Tabelle

Das würde ich nicht tun. Der eindeutige Index wäre "nur" Absicherung für weitere mögliche Tabelleneingaben.
Wenn man die Datensätze beliebig gegen einen eindeutigen Index laufen lässt, kann passieren, dass
- sich die DB aufbläht,
- Autowerte "verbraucht" werden (was jene besonders schmerzt, die fortlaufende Nummerierungen mögen).

 

Einfach mag das sein, du solltest aber auch über die negativen Begleiterscheinungen sprechen. *wink.gif*

Edit:
Ich sehe grade, Ebs hats schon erwähnt.
Das Aufblähen weist ja darauf hin, das erstmal alle Daten in die DB geschrieben und danach wieder gelöscht werden.
Löschen kann Access bekanntlich aber nicht, sondern nur als obsolet kennzeichnen - Löschen kommt dann erst beim Komprimieren.

 

Hallo,
@Klaus

Das ist aber ein sehr beschränkter Geschäftsumfang *wink.gif* ;
- nur eine Rechnung jeden Tag?

Wenn's keine globale Positionsnr. gibt, würde ich doch eher
auf einen Mehrfelder-Index aus Rechnungs- und Positions-Nr.
setzen.
gruss ekkehard

 

Vielen Dank für die Antworten.
Das Setzen eines Indexes auf das Rechnungsdatum hat es auf "ich nehme die Prüfung zeitlich nicht mal wahr" beschleunigt. *wink.gif*

Funktioniert jetzt perfekt.

Auch das mit der Datumsprüfung. Ich habe es mind. 10 mal mit verschiedenen Daten darauf angelegt die Prüfroutine zu überlisten.
Sie fängt aber zuverlässig alles ab.

Fall gelöst und erledigt.

Edit:
Die "negativen Begleiterscheinungen" bei der Nutzung von Indexes sind mir bekannt. Aber der höhere Datenumfang macht in meinem Fall jetzt den Kohl fett.
Es sind schon deutlich mehr Rechnungen / Tag im Schnitt.
Allerdings ist dies keine "Rechnungstabelle" sondern eine "Rechnungspositionen aller Rechnungen"-Tabelle von diesem und vom Vorjahr.
Da kommen schon was eine Menge Daten zusammen.

 

Dann verstehe ich nicht, warum du es nicht intelligent löst.
Beim Letzten mal war der Unterschied beim Import 3 Minuten zu drei Sekunden.

 

Du hast mich jetzt thematisch verloren.
Ich habe gar keine Laufzeiten angegeben, die Du jetzt hättest vergleichen können.

Vielleicht zum Verständnis:
In meiner Tabelle tragen keine User irgendwelche Daten ein oder können diese Verändern.
Ich importiere lediglich div. (AirPlus)-Rechnungsdateien in eine große Gesamtliste, damit die User global über alle Konten hinweg nach Rechnungspositionen suchen können.

Importiert werden die Daten von mir - und diese kleine Prüfabfrage soll mich nur darauf hinweisen, wenn schon Rechnungen mit gleichen Rechnungsdatum in der Tabelle vorhanden sind. (Denn dann wäre irgendwas schief gelaufen!)

Dies habe ich mit der DCount-Abfrage gelöst, die Dank Indizierung des Rechnungs-Datums-Feld nun ratzfatz läuft.

In dem Kontext wär es nett, wenn Du Deinen Vorschlag mit der intelligenten Lösung konkretisierst. Für Optimierungen bin ich immer offen!

 

Hallo!

Zusatzinfo:
Wenn es nur um die Prüfung geht, ob mindestens ein Datensatz existiert, ist DLookup vermutlich schneller, da DCount alle Datensätze zum angegebenen Kritierium finden muss, DLookup aber einfach den ersten Treffer liefert.

Code:

vs.
Code:

Du wirst aber vermutlich den Unterschied nicht wirklich bemerken, da es keine Rolle spielt, ob eine einzelne Prüfung 10 oder 100 ms läuft. *wink.gif*


Vielleicht kannst du die Prüfung direkt in die Insert-Anweisung einbauen.
Code:

mfg
Josef