Office: (Office 2016) Daten aus temporärer Tabelle in normalisierte Tabellenstruktur übernehmen

Hallo Leute,

ich nage da an einem Problem, dass mir so exotisch gar nicht vorkommt, trotzdem konnte ich über die Suche noch nichts finden. Eventuell benutze ich die falschen Suchworte, wenn also jemand einen brauchbaren Link hat, hilft mir das wohl auch schon.

Problemstellung:

Ich setze gerade eine Datenbank auf, die regelmäßig mit Daten aus bereitgestellten Excel-Listen aktualisiert werden soll. Diesen Prozess gilt es zu automatisieren.

Im Moment bin ich so weit, dass die Daten aus der Exceldatei via VBA in eine neue Tabelle in der Datenbank importiert worden sind. Nun gilt es, diese zu übernehmen, ich muss also die Daten auf mehrere Tabellen verteilen, die mit der Haupttabelle über 1:n bzw. n:m Beziehungen verknüpft sind. (Dubletten sollen übersprungen und die temporäre Tabelle soll nach Abarbeitung entfernt werden)

Wie gehe ich da ran? Kann man das über eine Anfügeabfrage machen?
Oder ist es besser, das über VBA zu lösen?

Kann mir jemand ein Beispiel nennen, das leicht nachzuvollziehen ist?

Danke im Voraus.

:)

 

Importtabelle in m:n-Beziehung auflösen
sowie
Grundlagen - SQL ist leicht (4) - Aktualisierung einer Tabelle

 

Vielen Dank, das schau ich mir mal an.

EDIT: Blöde Frage gelöscht

 

Ich hätte noch eine Verständnisfrage zum verlinkten Code (bin noch neu in SQL und versuche gerade das ganze Schritt für Schritt nach zu vollziehen):

In diesem Ausdruck steht ein einzelnes "T":

Code:

(..)

Ist das ein Alias für "tblTemp"?

Es ist nicht mit "AS" definiert und taucht auch sonst vorher nicht auf.. *confused.gif*

 

Siehe auch Grundlagen - SQL ist leicht (2) - Alias
Beim Tabellenalias ist das Schlüsselwort AS optional, kann also auch weggelassen werden.
Ich selber verwende es aber meist, da mir der Code dann lesbarer erscheint und sich auch eine Analyse einer Anweisung per Code besser an solchen Schlüsselworten orientieren kann.

 

Ahh so, danke. :-)

 

Ich fürchte, ich brauche noch mal Hilfe.

Ich habe zunächst die Werte aus der Excel Tabelle in die Datenbank übernommen, die direkt in der Master Tabelle stehen.

Das hat mit Code:

auch funktioniert.

Jetzt versuche ich, die Werte zu übernehmen, die in Access in 1:n Tabellen abgelegt werden sollen.
Da gibt es (u.a.) die Tabelle Tab_Origin mit den Feldern ID_Origin (Schlüsselfeld) und txtOrigin (Textfeld, für den Wert aus der Excel). In der Masterliste gibt es das Feld intOrigin (n), das mit Tab_Origin.ID_Origin (1) verknüpft ist.

Ich habe versucht, das n:m Beispiel darauf hin runter zu kürzen, leider klappt das aber nicht, ich schnall's nicht so recht.
Im Moment sieht das so aus:

Code:

Das funktioniert nicht, Fehler 3061, zu wenig Parameter übergeben.
Außerdem scheint mir auch der Bezug zur richtigen Position in der Tabelle zu fehlen (über txtMouseID).

Wo ist der Fehler?

 

Deine Darstellung kann ich nicht nachvollziehen.

Persönlich arbeite ich mich da entlang des Datenmodells. Verständlicherweise muss man ja zuerst in einer Primärtabelle den Datensatz angelegt haben, ehe man dessen PK als FK in eine Sekundärtabelle eintragen kann.

 

In der Primärtabelle "Tab_Animallist" ist der Datensatz durch den ersten von mir verlinkten Codeschnipsel angelegt worden. Durch das indizerte Feld "txtMouseID" ist er dann zu identifizieren.

Oder verstehe ich Dich jetzt falsch?

 

Wenn so etwas im "n-Bereich" auftritt (nochmaliges Anfügen?), bin ich grundsätzlich verwirrt, was ein weiteres Nachdenken darüber abschaltet.

Ist es denn so schwer, einmal in vollständigen Sätzen (Zusammenhängen) zu reden? Darunter würde ich hier eine Bspw.-DB mit intaktem Beziehungsfenster, was Datenmodell, benötigte Tabellen und angelegte Beziehungen zzgl. Importtabelle beinhaltet, verstehen.
Die verlinkte DB ist doch auch vollständig ...

 

Ah so, verstanden.

Anbei die DB mit der Excel-Importliste.

Das Problem tritt in der Funktion Daten_anfuegen_Click() auf.

 

Du verwendest einen Alias T der aber in diesem SQL String nicht definiert ist.
Außerdem ON ohne Join.
Auch der erste Subselect macht keinen Sinn.

Verstehest du das irgendwie oder kopierst du nur alles irgendwie zusammen?

 

Über konkrete Codefragen würde ich mir dann Gedanken machen, wenn sie dran sind. Im vorliegenden Fall muss man erst einmal einige Grundlagen klären und sich über Abläufe gewiss werden, ehe man mit konkreten Anweisungen losaktioniert. (Ehe ich losrenne, sollte ich mein Ziel wie z.B. Hamburg kennen und die nötige Himmelsrichtung dahin, um dahin zu kommen, wie auch mögliche Wege und Hindernisse - in See und Moor kann mal ganz schnell Feierabend sein mit Rennen.)
Im jedem Fall würde man aber sich zuerst mit Pur-SQL beschäftigen. VBA und die entsprechende Formatierung dazu der Anweisungen braucht man erst für eine automatisierte Folge der Ausführung wie auch für einen Überblick über die Anweisungen. Letzteres könnte man aber auch über sprechende Namen gespeicherter Einzelabfragen umsetzen.

Frage zuerst: Excelmappe und DB entsprechen der Realität? Die Spaltenüberschriften in der Exceltabelle erscheinen mir nicht alltagsüblich.
Hinweis: Abgesehen von einem extremen Interesse meinerseits an dem Fall (was aber nur selten vorliegt) möchte ich so eine Sache nur einmal anfassen, denn es macht schon einige Arbeit (der Teufel steckt im Detail). Auf ein zweites Mal, weil alles ganz anders ist, solltest Du also nicht hoffen, es sei denn, eine entsprechende Entschädigung schafft eine Entscheidungsumkehr.

Weiterhin sind bei Dir einige Orientierungs- und Lernprozesse nötig, damit wir uns auf einem sinnvollen gemeinsamen Niveau unterhalten können.
Basic: Mehrere Anfügeabfragen mit Datensatz-Teilinhalten auf die gleiche Tabelle Tab_animallist? Erkläre Du den Unterschied zwischen einer Anfügeabfrage und einer Aktualisierungsabfrage. Du, damit Du zeigst, dass Du es verstanden hast. In Folge dürfte Dir dann selber klar werden, dass Deine gezeigten Schritte schon nicht einem praktikablen Ablauf entsprechen.

Weiteres dann bei einem befriedigenden Feedback.

 

Zusatzbemerkung zu "Excelmappe und DB entsprechen der Realität?":
Bei dieser DB werden sichtbar u.a. Eltern-Kind-Verhältnisse verwaltet. Eine unikate Information auf ein Individuum wie "MHM-14036" findet sich in drei (!) Tabellen.

Wenn man alle Individuen in einer Liste haben wollte, braucht man eine Zusammenführung aus den Tabellen (problematisch). Wenn ein Kind zum Elternteil wird, fliegt Dir die Eindeutigkeit dann ganz auseinander.
Mit anderen Worten: Die Datenmodellierung scheint noch nicht fertig, sollte es aber sein, bevor man Daten einträgt oder gar importiert.

Zur Orientierung auf etwas Brauchbares kannst Du nach vergleichbaren Lösungen zu Stammbäumen, Hierarchien und dgl. recherchieren.

 

Die fertige Datenbank dient der Dokumentation von Forschungsergebnissen.

Mit den Felder "Father" und "Mother" wird weiter nichts gemacht, das muss halt nur mit dokumentiert werden.

Da werden keine Stammbäume erstellt oder so, also kein Problem. Aber danke, dass du darauf hingewiesen hast.

Mit dem Arbeitsschritt "Datenübernahme aus Excel" bin ich übrigens fertig, jetzt geht es an die Formulare.

@Moderation: Kann ich meinen Upload von weiter oben irgendwie löschen? Das ist veraltet und enthält falschen Code.