Hi,
ich habe eine Tabelle "Kundenliste". In dieser werden Firmen wie aber auch deren Mitarbeiter geführt. Um den Typ zu unterscheiden haben die Mitarbeiter in der Spalte Typ eine 1 und Firmen eine 2.
Jeder Firma sind eine unterschiedliche Anzahl an Mitarbeitern untergeordnet. Nun möchte ich, dass bei Mailings nur "Primär-Mitarbeiter" angeschrieben werden. Diese sind aber noch nicht definiert. Ich möchte dies nun nachträglich tun. Meine Idee war daher erst eine normale Abfrage, mit der jeweils die ersten Mitarbeiter Selektiert werden:
SELECT Kundenliste.Type, Kundenliste_1.Type, Kundenliste.Firmenname, First(Kundenliste_1.ID_Kunde) AS ErsterWertvonID_Kunde
FROM Kundenliste AS Kundenliste_1 INNER JOIN Kundenliste ON Kundenliste_1.ParentIDNeu = Kundenliste.ID_Kunde
GROUP BY Kundenliste.Type, Kundenliste_1.Type, Kundenliste.Firmenname
HAVING (((Kundenliste.Type)=2) AND ((Kundenliste_1.Type)=1));
Nun soll eine zweite Aktualisierungs-Abfrage, welche die erste Abfrage als Grundlage hat, die Spalte "IsPrimaryContact" mit dem Wert "True" füllen (es ist ein Ja/Nein Feld - dieses soll also angehakt werden):
UPDATE Abfrage_Primärkontakt_1 INNER JOIN Kundenliste ON Abfrage_Primärkontakt_1.ErsterWertvonID_Kunde = Kundenliste.ID_Kunde SET Kundenliste.IsPrimeryContact = True
WHERE (((Kundenliste.IsPrimeryContact)=False));
Die Profis werden es sicher wissen: es geht nicht :o :o :o
Ich erhalte die Fehlermeldung: "Operation muss eine aktualisierbare Abfrage verwenden".
Wie kann ich denn die Aufgabe nun lösen?
Hallo,
ZitatIn dieser werden Firmen wie aber auch deren Mitarbeiter geführt.
das ist schon mal grundsätzlich der völlig falsche Ansatz.
Die Mitarbeiter gehören in eine extra Tabelle mit einem Fremdschlüssel zu ihrer Firma. Der extra Tabelle kannst Du dann noch ein Ja/Nein Feld einbauen das den "Primär-Mitarbeiter" kennzeichnet. Ein "Primär-Mitarbeiter" kann ja auch wechseln.
Dein Vorhaben geht ohnehin nicht, weil gruppierte Abfragen nicht aktualisierbar sind, auch nicht mit einem Trick.
Zitat von: MzKlMu am Februar 24, 2016, 20:41:47
das ist schon mal grundsätzlich der völlig falsche Ansatz.
Nun, das sehe ich nicht so. Es geht ganz prima. Die Struktur habe ich von einem MS CRM Programm so übernommen. Firmen und Mitarbeiter nutzen fast identische Felder wie Straße, Ort, Telefon, Mail usw. Ich sehe nicht denn Sinn, diese gleichen Informationen in eine andere Tabelle zu übernehmen.... Die Mitarbeiter haben die FirmenID in einem ParentID Feld. Aber das steht ja auch nicht zum Thema.
Dann vielen Dank. Ich muss das dann halt anders lösen.
Hallo,
egal, wo Du das her hast, es ist falsch mag es auch noch so gut funktionieren. Firmen und deren Mitarbeiter sind zu trennen.
ZitatDie Mitarbeiter haben die FirmenID in einem ParentID Feld.
Das ist ja schon der 1. Schritt für eine Trennung.
Die Anschriften gehören dann als Fremdschlüssel in die jeweiligen Tabellen.
Dann hast Du auch keine redundanten Daten.
Das solltest Du ändern, Du wirst im Laufe der weiteren Entwicklung noch erkennen, dass es besser wäre.
Ich hab es lösen können. Immerhin ließ sich aus der Gruppierten Abfrage eine Tabellen-Erstellungsabfrage kreieren. Diese "Hilfstabelle" konnte ich dann in einer Aktualisierungsabfrage mit der Kundenliste verbinden und so die Aktualisierung durchführen.
Hallo,
Du kannst es drehen und wenden wie Du willst, Du kannst mich nicht überzeugen, der Aufbau ist falsch. Mag es auch noch so gut funktionieren.
Aber Du musst ja nicht mich überzeugen, ich wollte es ja bei Dir versuchen, hat halt nicht geklappt. ;D
Lieber Klaus, es ging doch primär um die Frage der Umsetzung des Problems aus meinem Eröffnungsthread - weniger um die Optimierung meiner Datenbank. Und bezüglich der Fragestellung habe ich selbst die Lösung gefunden, dies über eine erstellte Hilfstabelle mittels gruppierter Abfrage.
Ich bin doch sehr offen für Verbesserungsvorschläge und ich habe lang hin und her überlegt, die Daten zu trennen und mich dann dagegen entschieden aus verschiedenen Gründen. Im Moment läuft es mit mehr als 10.000 Kontaktdatensätzen super.
Hallo,
im Grunde ist mir ja egal, wie Du Deine DB aufbaust, aber Du hast nun mal hier um Rat gefragt. Und da wird halt beraten, ob Du das willst oder nicht. ;D
Eine Firma hat mehrere Mitarbeiter, speicherst Du dann zu jedem Mitarbeiter jeweils die komplette Firma ?
Das gibt doch jede Menge redundante Daten.
Und mit einem normalisierten Datenmodell wäre ja Deine jetzige Lösung überflüssig.
Zitat von: MzKlMu am Februar 25, 2016, 13:31:15
Hallo,
im Grunde ist mir ja egal, wie Du Deine DB aufbaust, aber Du hast nun mal hier um Rat gefragt. Und da wird halt beraten, ob Du das willst oder nicht. ;D
Eine Firma hat mehrere Mitarbeiter, speicherst Du dann zu jedem Mitarbeiter jeweils die komplette Firma ?
Das gibt doch jede Menge redundante Daten.
Und mit einem normalisierten Datenmodell wäre ja Deine jetzige Lösung überflüssig.
Ähhm nein.. ich speichere nicht die gesamte Firma. Hier ein Beispiel:
tbl_Kontaktdaten
ID| Firmenname | Straße | Ort | Typ| Anrede | Nachname | ParentID | IsPrimary
1 | Testfirma | Weg 1 | Neuss | 2 | | | |
2 | | Straße 2 | Ort 2 | 1 | Herr | Rummel | 1 | -1
3 | | Straße 5 | Ort 3 | 1 | Herr | Kuhn | 1 | 0
4 | Minifischi | Straße 2 | Ort 4 | 2 |
5 | | Straße 7 | Ort 13| 1 | Herr | Müller | 4 | -1
Ich weiß auch nicht warum die Lösung durch eine Splittung auf 2 Tabellen dann überflüssig wäre...
Hallo,
ist das Beispiel authentisch?
Soll heißen: Manche DS enthalten keinen Firmennamen und sind denzufolge leer?
Dann wird es tatsächlich Zeit, das Ding ad acta zu legen...
Ja, ist authentisch.
Zitat von: DF6GL am Februar 25, 2016, 16:25:33
Dann wird es tatsächlich Zeit, das Ding ad acta zu legen...
Was meinst Du damit und warum?
Hallo,
ZitatWas meinst Du damit und warum?
weil Du leere Felder hast.
Bei der Firma und bei den Personen.
Und mit der ParentID hast Du ja das Problem schon erkannt, das ist ja schon die halbe Aufteilung. Und die Firmentabelle kriegt einen Fremdschlüssel zu der dann extra Personentabelle in der der Primäransprechpartner gespeichert wird. Den kannst Du dann jederzeit per Kombi wählen bzw. ändern. Ohne einen Buchstaben Code. So wie Du das jetzt machst entfällt das ersatzlos.
Damit wirst Du auf Dauer nicht viel Freude haben. Das ist ein Holzweg.
Ich will ja nicht unbelehrbar sein... aber das Kombi bekomme ich auch ohne Code hin:
SELECT Kundenliste.ID_Kunde, Kundenliste.Nachname
FROM Kundenliste
WHERE (((Kundenliste.Type)=1) AND ((Kundenliste.ParentIDNeu)=[Formulare]![frm_Kundenform_haupt]![ID_Kunde]));
Hallo,
was hat das Kombi jetzt damit zu tun? Darum geht es nicht.
Wenn der Tabellenaufbau tatsächlich so wie im Beispiel gezeigt ist (wodran ich aus Hoffnung noch zweifle), dann ist die Db einfach nicht zu gebrauchen, bzw. liefert chaotische Daten.
Zitatmit der jeweils die ersten Mitarbeiter Selektiert werden
Wodran ist zu erkennen, dass es der "erste" Mitarbeiter ist?
Zeige mal einen Screenshot vom Beziehungsfenster
Ich denke wir sollten hier beenden. Das führt zu nix. Die Datenbank arbeitet seit Monaten hervorragend und liefert keine chaotischen Daten! Die Frage "Wo dran ist zu erkennen, dass es der 'erste' Mitarbeiter ist?" stellte sich mir gar nicht, da es egal ist welchen Datensatz die Datenbank dafür nimmt. Wichtig war nur, dass sie einen nimmt. In der Summenabfrage wählte ich einfach "erster" als erster Eintrag im Schlüsselfeld.
Die Beziehungen zur Kundenliste sind nicht starr festgelegt sondern werden individuell nach Anforderung in der Abfrage aufgebaut. Man muss doch nur die Typen unterscheiden. Man kann doch auch in einer Abfrage die gleiche Tabelle zwei mal aufnehmen, man kann Sie sogar anders benennen (Kundenliste und Kundenliste As Mitarbeiter).
Es mag zwar sein, dass normalerweise diese Daten zu trennen sind, aber ich habe mich erstmal für diese Vorgehensweise entschieden, weil sie an manchen Stellen in Ihrer Funktionalität Vorteile bringt. Bisher kann mir hier auch keiner sagen, was konkret durch dieses Modell nicht funktionieren soll. Sie ist weit davon entfernt "nicht zu gebrauchen" zu sein oder einen "Holzweg" darzustellen. Das Modell habe ich von Microsofts CRM Outlook BCM so übernommen (vergl. MSSQL/MSSMLBIZ dbo.ContactMainTable).
Wir sollten schließen :)
Hi,
ok, es ist ja deine DB und du arbeitest damit.... 8)
Ich gehe auch zur Bank und hole Geld ab, egal von welchen Konto es stammt... :P
Hallo datekk,
ZitatDie Beziehungen zur Kundenliste sind nicht starr festgelegt sondern werden individuell nach Anforderung in der Abfrage aufgebaut
Das sind keine Beziehungen (Relations), das sind JOINs.
gruss ekkehard