Import von DS - Duplikate per Index vermeiden

Moderator: ModerationP

Import von DS - Duplikate per Index vermeiden

Beitragvon Raubgraf » 19. Jul 2019, 17:28

Hallo allerseits,

ich bin ein bisschen ratlos...

Die tbl_bankumsatz verfügt über einen Index über die Felder Buchungsdatum, Verwendungszweck, Betrag
Primäschlüssel:nein
unique: ja
nullwerte ignorieren: nein

Wenn ich mit dem nachfolgenden Query importiere wird der gleiche DS mehrfach importiert - aber nur bei denen wo Verwendungszweck leer ist,
Habe ich was falsch eingestellt ?

Code: Alles auswählen
INSERT INTO tbl_bankumsatz ( id_bankverbindung, Auszugnummer, [Position], Buchungsdatum, Gegenseite, Verwendungszweck, Betrag, Saldo )
SELECT tbl_bankverbindung.idbankverbindung, temp_bankumsatzsfirm.Auszugnummer, temp_bankumsatzsfirm.Position, temp_bankumsatzsfirm.Buchungsdatum, temp_bankumsatzsfirm.Gegenseite, temp_bankumsatzsfirm.Buchungstext, temp_bankumsatzsfirm.Betrag, temp_bankumsatzsfirm.Saldo
FROM temp_bankumsatzsfirm LEFT JOIN tbl_bankverbindung
ON temp_bankumsatzsfirm.IBAN = tbl_bankverbindung.IBAN
WHERE (((tbl_bankverbindung.idbankverbindung) Is Not Null));


Besten Dank für Eure Hilfe !
Raubgraf
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 206
Registriert: 13. Feb 2017, 11:18

Re: Import von DS - Duplikate per Index vermeiden

Beitragvon mmarkus » 19. Jul 2019, 19:20

Wie du schon bemerkt hast geht das nicht.

Null ist bei Access bei einem eindeutigen Index nicht möglich.
Bei einem String genügt ein leeres Textfeld.
Bei einer Zahl muss ebenso ein Wert drin stehen.

LG Markus
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1529
Registriert: 16. Apr 2012, 16:07
Wohnort: Oberösterreich

Re: Import von DS - Duplikate per Index vermeiden

Beitragvon Kerstin83 » 19. Jul 2019, 20:01

gelöscht
Zuletzt geändert von Kerstin83 am 20. Jul 2019, 09:43, insgesamt 1-mal geändert.
Ich hasse Leute, die Sätze nicht zuende

Tchibo Induktions-Milchaufschäumer
Standby-Betrieb: 18 Watt.
Pro Jahr: 80 kg CO2 (und 30 Euro)

- Ohne Kommentar -
Kerstin83
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1376
Registriert: 03. Aug 2005, 13:29
Wohnort: Zur Zeit im schönen Berlin

Re: Import von DS - Duplikate per Index vermeiden

Beitragvon Raubgraf » 19. Jul 2019, 21:39

mmarkus hat geschrieben:Wie du schon bemerkt hast geht das nicht.
Null ist bei Access bei einem eindeutigen Index nicht möglich.
LG Markus


Ja offenbar doch ? Sonst würden ja die DS nicht doppelt angelegt ?

Bei einem String genügt ein leeres Textfeld.

Wofür genügt das? Um den Index auszuhebeln und ein Duplikat zuzulassen ?
Raubgraf
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 206
Registriert: 13. Feb 2017, 11:18

Re: Import von DS - Duplikate per Index vermeiden

Beitragvon Gast » 20. Jul 2019, 07:28

NULL ist in einem eindeutigen Index möglich, nicht jedoch in einem Primärschlüssel.
Im Zweifelsfall würde ich in der Tabellendefinition bereits die Einzelfelder so absichern, dass da Einträge erfolgen müssen.
Spielt das nach Datenlage überhaupt eine Rolle, können die Quellfelder Buchungsdatum, Verwendungszweck, Betrag ohne Inhalt sein?
Verwendungszweck ist hoffentlich kein ausgefülltes Memo.

Ansonsten sollte der eindeutige Index in der Tabelle auf jeden Fall wirken und dort keine Duplikate zulassen, sonst kannst Du den ganzen Mist wegwerfen, inkl. Officeinstallation (wo Jet-Engine / ACE beheimatet sind).

Qualifizierter wäre dann die Abfrage, wenn man zum einen ausschließt, dass die Datenquelle selber keine Duplikate in sich trägt, und zum anderen, wenn man Ziel und Quelle einer Inkonsistenzprüfung unterzieht und so eben nur neue Datensätze und dann nur einfach anfügt.
Auch hier müsste man einen Blick auf die Datenlage werfen, um zu sehen, was nötig ist.

Die gezeigte Abfrage erscheint schon rein technisch unstrukturiert. tbl_bankverbindung wird per OUTER JOIN angebunden, das einzig verwendete Feld daraus wird aber auf nicht NULL geprüft (NOT indexschädlich). Das würde man gleich auf einen INNER JOIN zusammenstreichen und gänge dann auch der unlogisch wirkenden Verknüpfung (Umsätze und Bankverbindung, wenn vorhanden) aus dem Weg.
Gast
 

Re: Import von DS - Duplikate per Index vermeiden

Beitragvon Raubgraf » 20. Jul 2019, 07:56

NULL ist in einem eindeutigen Index möglich, nicht jedoch in einem Primärschlüssel.

Das bedeutet : ich habe zumindest den Index nicht falsch gebaut :) - aber das Problem besteht trotzdem :(

Wäre zu empfehlen statt des bisherigen Primärschlüssels idbankumsatz die Einzelfelder zum Primärschlüssel zu machen ?


Im Zweifelsfall würde ich in der Tabellendefinition bereits die Einzelfelder so absichern, dass da Einträge erfolgen müssen.
Spielt das nach Datenlage überhaupt eine Rolle, können die Quellfelder Buchungsdatum, Verwendungszweck, Betrag ohne Inhalt sein?
Verwendungszweck ist hoffentlich kein ausgefülltes Memo.


Es gibt Banken die senden bestimmte Buchungen ohne Verwendungszweck zum Beispiel Kontoführungsgebühren o.ä. also kann ich nicht auf not nul absichern bei Eingabe.
Meine Idee wäre einen zusätzliche Bedingung in die Abfrage - Wenn Verwendungszweck is nul dann Verwendungszweck = Datum & " " & Betrag (Syntax richtig?)

Ansonsten sollte der eindeutige Index in der Tabelle auf jeden Fall wirken und dort keine Duplikate zulassen, sonst kannst Du den ganzen Mist wegwerfen, inkl. Officeinstallation (wo Jet-Engine / ACE beheimatet sind).

Also doch idbankumsatz als Primärschlüssel lassen... ?

Qualifizierter wäre dann die Abfrage, wenn man zum einen ausschließt, dass die Datenquelle selber keine Duplikate in sich trägt, und zum anderen, wenn man Ziel und Quelle einer Inkonsistenzprüfung unterzieht und so eben nur neue Datensätze und dann nur einfach anfügt.
Auch hier müsste man einen Blick auf die Datenlage werfen, um zu sehen, was nötig ist.

Datenquelle hat zwingend Duplikate da immer alle Umsätze rückwirkend -360 Tage geholt werden, deshalb ja mein Versuch einer Inkonsistenzprüfung via Index, alternativ könnte ich noch eine Duplikatprüfung nach dem Import drüberlaufenlassen

Die gezeigte Abfrage erscheint schon rein technisch unstrukturiert. tbl_bankverbindung wird per OUTER JOIN angebunden, das einzig verwendete Feld daraus wird aber auf nicht NULL geprüft (NOT indexschädlich).

Habe ich leider inhaltlich nicht verstanden.Das würde man gleich auf einen INNER JOIN zusammenstreichen und gänge dann auch der unlogisch wirkenden Verknüpfung (Umsätze und Bankverbindung, wenn vorhanden) aus dem Weg.
[/quote]
Die temp_bankumsatzsfirm ist nur der Accessname für eine txt datei die durch das Bankingprogramm automatisch bereitgestellt wird. Ich habe nur die IBAN um die Buchungen zuzuordnen...

danke für die Geduld
Raubgraf
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 206
Registriert: 13. Feb 2017, 11:18

Re: Import von DS - Duplikate per Index vermeiden

Beitragvon Gast » 20. Jul 2019, 08:55

Inkonsistenzprüfung via Index

Für mich ist das ein Widerspruch in sich => Kopf gegen Mauer, wenn es weh tut, ist da gerade Mauer. Prüfung hieße für mich: Vorher schauen und nicht gegen die Mauer, keine Schmerzen. Ein Indexfehler ist auch ein Fehler.

also kann ich nicht auf not nul absichern

Da dürfte also die Index-"Lösung" ihre Grenzen erreicht haben (zur Performance trägt der Index aber immer noch bei). Also sollte man sich auf eine Codelösung fixieren und den Index nur begleiten lassen (was ich von Haus aus tun würde).

da immer alle Umsätze rückwirkend -360 Tage geholt werden

Hm..., da erzeugt die Buchungssoftware nicht nur neue Datensätze, die angefügt werden, sondern auch neue "historische", die in den Zeitraum hinein gestreut werden??
Ich würde mich ja aus Datenmengen- und Performancegründen gezielt nur mit neuen Datensätzen beschäftigen, so aus Prinzip. Also filtern statt bequem den ganzen Haufen rumzuschieben.

Das mit dem INNER JOIN war jetzt mehr eine grundsätzliche Betrachtung und muss nicht zwingend zu Deinen Realbedingungen passen. Man kann Ahnungen und Schlussfolgerungen nur aus den beigebrachten Darstellungen beziehen, und Erzählungen und eine reale vollständige Beschreibung des Gegenstandes (am Ende ein Demoprojekt mit Tabellen und allen ihren Indizes und Beziehungen und einigen Demodaten, die aber auch repräsentativ die Problemdatensätze beinhalten) können sehr verschiedene Dinge sein.

Z.B.: Was ist id_bankverbindung? Da wird etwas verwendet und eingefügt, und ein Betrachter kann nur raten, was da passiert strukturell und datentechnisch. Ein JOIN ist in einer Abfrage auch sehr geeignet, Datensatzanteile aus Tabellen zu vervielfältigen ... wer wundert sich dann über (zu)viele Datensätze?
Gast
 

Re: Import von DS - Duplikate per Index vermeiden

Beitragvon mmarkus » 28. Jul 2019, 11:37

Raubgraf hat geschrieben:
mmarkus hat geschrieben:Wie du schon bemerkt hast geht das nicht.
Null ist bei Access bei einem eindeutigen Index nicht möglich.
LG Markus


Ja offenbar doch ? Sonst würden ja die DS nicht doppelt angelegt ?


Du kannst einen Datensatz anlegen, aber es wird kein Index erstellt, zumindest kannst du den Datensatz ja problemlos mehrfach erstellen.
Anscheinend spielt es keine Rolle, welche Einstellung man beim Index macht.
Das Thema wurde übrigens schon oft behandelt und das Verhalten ist nichts Neues.

mmarkus hat geschrieben:Bei einem String genügt ein leeres Textfeld.

Raubgraf hat geschrieben:Wofür genügt das? Um den Index auszuhebeln und ein Duplikat zuzulassen?


Mit einem Leerfeld wird ein eindeutiger Index möglich und man kann den Datensatz nicht mehrfach anfügen.
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1529
Registriert: 16. Apr 2012, 16:07
Wohnort: Oberösterreich

Re: Import von DS - Duplikate per Index vermeiden

Beitragvon Doming » 12. Aug 2019, 11:57

Moin Raubgraf,

was ist eigentlich die Aufgabenstellung?
Ich frage, weil ich gerade versuche, meine Kontobewegungen aus einem CSV-Export aus dem Onlinebanking in eine DB einzupflegen.
Ich mache das, indem ich die CSV-Datei Buchungssatzweise mit einer Open-Recordset Schleife einlese.
Aus der bestehenden Ziel-Tabelle hole ich mir das jüngste Datum und vergleiche in der Schleife, ob die Buchungen älter sind.
Wenn sie das gleiche Datum tragen, frage ich den User, denn es kann ja sein, dass seit dem letzten Export noch Buchungen an dem Tag durchgeführt wurden.
Jüngere Buchungen werden natürlich gleich übernommen.
Zusätzlich habe ich noch eine Alias-Tabelle, denn es kann sein, dass Buchungen verschiedene Schreibweisen für den Zahlungspartner haben, z.B. "Müller Klempner" und "Klempner Müller".
Die Schleife guckt dann in der Alias Tabelle nach und vergleicht die Namen. Findet sie nichts passendes, wird nachgefragt, ob der Name ein neuer Partner ist oder einem Bestehenden zugeordnet wird.
Im Datensatz wird dann nur die Partner-ID hinterlegt.
Meine Bank gibt interne Buchungen (Zinsen z.B.) ohne Angabe eines Namens an, dafür sind dann im Verwendungszweck teilweise über 10 Zeilenumbrüche. Solche Buchungen bekommen dann bei mir einen Namen zugewiesen (ist ja immer von der Bank) und die verschiedenen Zeilen des Betreffs schreibe ich in eine neue Tabelle, die dann die ID des Buchungssatzes mitbekommen.
In einem Endlosformular werden mir die verschiedenen Zeilenumbrüche in bis zu 14 Textfelder angezeigt, damit das ganze flüssig lesbar bleibt.

Gruß
Doming
Benutzeravatar
Doming
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 127
Registriert: 01. Jul 2014, 05:19

Re: Import von DS - Duplikate per Index vermeiden

Beitragvon Kerstin83 » 13. Aug 2019, 17:11

hmmm, ich frage mich, wo hier eigentlich das Problem ist. Das Onlinebanking-Programm liefert doch einen eindeutigen Index. Oder etwa nicht ?

Beim Import werden alle Indizes, die noch nicht eingelesen wurden, importiert.

Wo gibt es da ein Problem ?
Ich hasse Leute, die Sätze nicht zuende

Tchibo Induktions-Milchaufschäumer
Standby-Betrieb: 18 Watt.
Pro Jahr: 80 kg CO2 (und 30 Euro)

- Ohne Kommentar -
Kerstin83
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1376
Registriert: 03. Aug 2005, 13:29
Wohnort: Zur Zeit im schönen Berlin

Re: Import von DS - Duplikate per Index vermeiden

Beitragvon Raubgraf » 17. Aug 2019, 12:11

Ich würde gern noch eine Nachfrage stellen:

Ich habe also jetzt eine Tabelle mit den Bankbuchungen. jetzt möchte ich diese Kategorisieren wobei es auch zu splits kommen kann.

Ich habe also eine buchungsdetailtabelle wo ich zu jeder Bankbuchung die Details in einem oder mehrerern DS speichern kann.

Hat jemand eine Empfehlung wie ich das praktischerweise angehen sollte ?

Also ich habe ein UFO1 mit den Buchungen (editierbar) und könnte jetzt ein verknüpftes UFO2 mit den DetailDS danebenpacken. Sieht nur nicht schön aus...Ich will ja in UFO1 in der Liste bereits sehen was "gebucht" ist und was nicht. Aber das würde ich ja erst beim anklicken des DS in UFO1 im UFo2 angezeigt bekommen...
Raubgraf
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 206
Registriert: 13. Feb 2017, 11:18


Zurück zu Access Forum (provisorisch)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste