Office: (Office 2003) Anfüge abfrage

Ich würde erstmal mit Abfragen weitermachen, die du erstmal per Hand anstößt. Wenn das läuft - und erst dann - kannst du wagen, das ín Code zu gießen.

Das, was du bisher mit den Kunden gemacht hast, passiert jetzt analog mit den verträgen. Welche gibt schon, welche sind neu, und die dann anfügen.

 

Frage : In der Abfrage um die Projektdaten zu isolieren:

Müssen hier Daten, die aus anderen Tabellen über Schlüssel ermittelt werden mit ausgewählt werden?

Bsp. Kundendaten??


Kurz zum Aufbau der DB

tblProjekte (Kunden ID, VB ID, Segment ID, Status ID, Projektdetails)
tblKunden, tblVertriebsbereich, tblSegment, tblStatus,..

 

Gings nicht eben noch um Kunden und Verträge? Wo kommen die Projekte jetzt her?

 

Die Verträge laufen unter dem Namen Projekte da es sich um individualverträge handelt..

Also wie oben beschrieben zusammengesetzt..

 

Hi,

wenn du Daten importierst, solltest du dir bei jeder Spalte Gedanken machen, in welcher Tabelle der Zieldatenbank diese Information wiedergefunden werden könnte.

• Kundendaten in der Kundentabelle, anhand Nr und Name.
• Vertragsdaten (Laufzeitbeginn, Tarifwahl etc) in den Verträgen, dabei kommen nur die Verträge des jeweiligen Kunden infrage.

Genaueres lässt sich erst dagen, wenn du mal eine abgespeckte und anonymisierte Datenbank mit ein paar Demosätzen hochlädst. Ich werde das sicher nicht komplett freihändig nachbauen.

 

Hier eine abgespeckte Version..

Tabellen Vertriebsbereich und Salesmanager sind vordefiniert..

 

- Der Schlüssel in einer Collection muss eindeutig sein, bei der Zweit-Zuweisung eines vorhandenen Wertes gibt es also einen Fehler.
- Die Collection wird laut obigem Vorschlag aus einer Mastertabelle gefüllt, wo man natürlich auch von einer Eindeutigkeit ausgehen muss. Hier allerdings nicht vom Primary Key der Tabelle (der wird ja über die Collection ermittelt, um ihn in einer weiteren Tabelle als Foreign Key verwenden zu können), sondern über wesentliche Werte in der Tabelle.
Wesentlicher Wert: In den obigen Tabellen genügte dazu ein Feld, bei dieser Tabelle sind das dann zwei Felder (Kundenname, KdNr). Also müssen diese beiden Felder verkettet als Key für die Collection eingetragen werden, also etwa
Code:

Beim Auslesen muss man umgedreht darauf achten, dass der Key aus mehreren Feldern zusammengesetzt ist.

Hinweis zur (bereits geklärten) Problematik der Duplikate in der Mastertabelle:
- Ein eindeutiger Index, bei mehreren Feldern in Kombination ein eindeutiger zusammengesetzter Index, verhindern zuverlässig Duplikate.
- Eine Inkonsistenzprüfung innerhalb der Anfügeabfrage, wie sie eingangs verwendet wurde, macht das auf die "weiche" Art. Sie erzeugt keine Schlüsselverletzungen und begrenzt "bewegte" Datenmenge.
Eine Inkonsistenzprüfung gleicht aber jeweils einen Quelldatensatz mit der Zieltabelle ab, ob dieser dort vorhanden ist. Sie erfasst nicht, ob in der Quelltabelle selber Duplikate vorhanden sind. Diese würden in Summe übertragen, weil sie in der Zieltabelle nicht vorhanden sind.
Hier wird dann zusätzlich ein Ausschluss von Duplikaten in der Quelltabelle erforderlich, bspw. über eine passende Gruppierung, in einfacheren Fällen genügt ein DISTINCT.

 

Hi,

hier ergänzt. Führe die Abfragen in Reihenfolge der Numerierung aus.

Die Projektnummer hat überigens in den Tabellen Import und Projekte unterschiedlichen Datentyp. Ich habe mir erlaubt, das anzupassen.

 

Würde folgende Vorgehensweise funktionieren:

1. Kunden aus der Importtabelle gruppiert abfragen
2. Neue Kunden anfügen
3. Die von dir vorgeschlagene FindFirst mit Edit/Add New Funktion
4. FillCollection für Customer (an Hand der Ursprungsstruktur)

Code:

???

 

1 + 2 ... ja: Wäre bei mir eine Abfrage (ein Vorgang)
3 ... ja, allerdings helfen dann Tabellenfelder im Recordset nicht mehr weiter:
Code:

Das (hier) dritte Feld müsste dann ebenfalls aus verknüpften Feldern bestehen (erzeugen in einer Abfrage), da sonst der (zusammengesetzte) Schlüssel nicht auffindbar ist.
4 ... funktioniert so nicht. Die Collection erhält zwei Werte (Key und Item). Bitte auch in der VBA-Hilfe ausführlich nachlesen - verstehend anwenden ist besser als Try&Error.
Etwa so sollte es beim Erzeugen der Collection aussehen:
Code:

War mein Beispiel so unverständlich?

Chr(124) = senkrechte Linie ... ist ein (beliebig zu wählendes) Trennzeichen, um die Feldwerte sauber voneinander abgrenzen zu können und eine Eindeutigkeit beizubehalten. Bei manchen Verkettungen könnte es sonst problematisch werden:
Code:

Außerdem könnte es evtl. notwendig werden, verkettete Ausdrücke wieder trennen zu müssen. Da weiß man ein schönes Trennzeichen zu schätzen.

 

Hi,

hat #53 nicht funktioniert?

 

# 53 funktioniert zwar aber: Beim ersten Ausführend er Anfügeabfrage übernimmt er alle Datensätze. Beim zweiten mal, hängt er die Kunden dran, die noch keine KdNr besitzen)

Projekte übernimmt er leider auch ohne zu bemerken dass diese schon vorhanden sind

hmmm

 

Zu #55

Code:

Könnte ich so ein verknüpftes Feld generieren?
SELECT Import.[Customer Name] AND Import.[Customer No] AS CKey

 

Was ist denn ein neuer Kunde? Einer, dessen name noch nicht vorkommt, dessen Nummer noch nicht vorkommt, oder einer, wo bedies noch nicht vorkommt?

Die Abfragen versuchen, die neuen Elemente zu ermitteln, indem sie "alle X, die nicht in Y sind" bilden. Das "nicht drin sein" wird durch Leftjoins und Bedingngen erreicht. Die kannst du anpassen.

Meine DB diente zur Veranschaulichung, d.h. zum Erkennen und Verstehen. Sie diente nicht unebdingt dazu, dir diese Arbeit abzunehmen.

 

Ja.

Aber im konkreten Fall sollte man zusätzlich beachten,
- dass man genau so verknüpft wie beim Füllen der Connection (wenn man den Wert wiederfinden will)
- dass die Abfrage noch mehr Felder enthalten müsste, da noch mehr Schlüssel ermittelt und Felder in der Zieltabelle ergänzt/aktualisiert werden sollen,
- dass die Reihenfolge passt (wenn man die Feldauflistung per Index verwendet) oder die Feldnamen passen (wenn man die Feldauflistung per Name verwendet).