Ich habe ein Hauptformular für die Kalkulation. In diesem Hauptformular ist das Unterformular für die Kalkulation des Materials.
Jetzt sollte ich die gesamte Kalkulation kopieren.
Hauptformular mit Daten im Unterformular.
Den Datensatz im Hauptformular kopiere ich mit folgendem vbacode:
Set dbs = CurrentDb
Set rstKalk = dbs.OpenRecordset("t_auftrag_kalk")
rstKalk.AddNew
rstKalk!Kalknr = DMax("KalkNr", "t_auftrag_kalk") + 1
rstKalk!auftragnr_kalk = Me.auftragnr_kalk
rstKalk!kundennr_kalk = Me.kundennr_kalk
rstKalk!kalkdatum = Date
rstKalk!materialpreis_lager = Me.materialpreis_lager
rstKalk!materialpreis_sonstige = Me.materialpreis_sonstige
rstKalk!Verzinkungskosten = Me.Verzinkungskosten
rstKalk!FK_janein = -1
rstKalk!FKSatz = Me.FKSatz
rstKalk!Fixkosten = Me.Fixkosten
rstKalk!Multiplikator = 1
rstKalk.Update
Die Daten im Unterformualar zu kopieren sollte nach meinen Recherchen im Internet mit einer Anfügeabfrage funktionieren.
Der SQL code für diese Anfügeabfrage:
INSERT INTO t_Kalkmaterial ( IDKalkmaterial, FSKalkNrMaterial, auftragnr_kalk_m, Artikelgruppe, Artikelnummer, Artikel, Dimension, VKEinheit, VKjeEinheit, MENGE, GesamtVK, Stueck, Laenge, Breite, kgProEinheit, verzinken, VerzBetrag )
SELECT t_Kalkmaterial.IDKalkmaterial, t_Kalkmaterial.FSKalkNrMaterial, t_Kalkmaterial.auftragnr_kalk_m, t_Kalkmaterial.Artikelgruppe, t_Kalkmaterial.Artikelnummer, t_Kalkmaterial.Artikel, t_Kalkmaterial.Dimension, t_Kalkmaterial.VKEinheit, t_Kalkmaterial.VKjeEinheit, t_Kalkmaterial.MENGE, t_Kalkmaterial.GesamtVK, t_Kalkmaterial.Stueck, t_Kalkmaterial.Laenge, t_Kalkmaterial.Breite, t_Kalkmaterial.kgProEinheit, t_Kalkmaterial.verzinken, t_Kalkmaterial.VerzBetrag
FROM t_auftrag_kalk INNER JOIN t_Kalkmaterial ON t_auftrag_kalk.Kalknr = t_Kalkmaterial.FSKalkNrMaterial
WHERE (((t_Kalkmaterial.auftragnr_kalk_m)=[Formulare]![f_Kalkulation]![auftragnr_kalk]));
Damit werden die Datensätze in die t_Kalkmaterial auch angefügt.
Nur sollte in den Fremdschlüssel FSKalkNrMaterial die neue Kalkulationsnummer des kopierten Datensatzes übernommen werden.
Ich schaffe es aber nicht in die Anfügeabfrage bei FSKalkNrMaterial diesen Wert = Max von t_auftrag_kalk zu
übernehmen.
FSKalkNrMaterial: DomMax([kalknr];"t_auftrag_kalk") liefert auch nicht das gewünschte Ergebnis
Kann mir jemand sagen, wie die Anfügeabfrage geändert werden muss oder wie eine Schleife für das Anfügen der Datensätze aussehen könnte.
Vielen Dank im Voraus für jede Hilfe!
Günther
Formular Daten mit Unterformular Daten kopieren im neuen Datensatz (als Vorlage) (https://www.access-o-mania.de/forum/index.php?topic=26131.msg155843#msg155843)
Ich versuche die Frage nochmals auf das Wesentliche zu reduzieren.
In einem Hauptformular mit Unterformular soll der gesamte Datensatz kopiert werden.
Im Hauptformular funktioniert das gut mit Recordset.
Im Unterformular (mehrere Zeilen) können die Datensätze mit einer Anfügeabfrage kopiert werden.
Problem: Wie kann ich in der Anfügeabfrage beim Feld FSKalkNrMaterial den Maximalwert aus der Tabelle FSKalkNrMaterial Feld KalkNr übernehmen?
Abfrageentwurf siehe Bild
Hallo,
in dem Link von Eberhard steht alles drin was Du brauchst, sehr ausführlich.
Und für den Datensatz des Hafo auch eine Anfügeabfrage verwenden.
Vielen Dank für eure Unterstützung.
Ich habe versucht mich durch den Code durchzukämpfen. Leider bin ich mit VBA nicht sehr versiert.
Bereits beim Versuch den Hinweis von Klaus auch die Daten des Hafo mit Anfügeabfrage umzusetzen scheitere ich.
Könnt ihr mir erklären was bei
Begintrans
db.Execute strSQL, dbFailOnError
lngArtIDNew = db.OpenRecordset("Select @@Identity")(0)
CommitTrans
passiert.
Fehler -Transaktion konnte nicht gestartet werden, bereits zu viele verschachtelte Transaktionen vorhanden
Mein Code:
BeginTrans
'--- tab.Artikel t_auftrag_kalk
strSQL = " INSERT INTO t_auftrag_kalk ( Kalknr, auftragnr_kalk, kundennr_kalk, kalkdatum, materialpreis_lager, materialpreis_sonstige, preis_leistung, Verzinkungskosten, FK_janein, FKSatz, Fixkosten,Multiplikator) " & _
" SELECT Kalknr, auftragnr_kalk, kundennr_kalk, kalkdatum, materialpreis_lager, materialpreis_sonstige, preis_leistung, Verzinkungskosten, FK_janein, FKSatz, Fixkosten,Multiplikator " & _
" FROM t_auftrag_kalk WHERE kalknr = " & Me!txtKalkNr
db.Execute strSQL, dbFailOnError
lngArtIDNew = db.OpenRecordset("Select @@Identity")(0)
CommitTrans
Hallo,
db.Execute strSQL, dbFailOnErrorKopiert den DS im HFo.
lngArtIDNew = db.OpenRecordset("Select @@Identity")(0)Speichert den zuletzt vergebenen PK.
Wenn "Kalknr" der PK ist (AutoWert?) muss der aus beiden Feldlisten
raus; - beim INSERT wird ja ein neuer vergeben, und das darf natürlich
nicht der letzte sein (der im SELECT).
Beim INSERT der DS aus dem UFo musst du dann im SELECT die Variable
"lngArtIDNew" einsetzen
... SELECT t_Kalkmaterial.IDKalkmaterial, " & lngArtIDNew & ", ...
gruss ekkehard
Vielen Dank für deine ausführlichen Erklärungen. Super dass du dir immer wieder für solche Anfänger wie mich Zeit nimmst. Mich fasziniert Access, aber ich bin eben am Lernen.
Ich steh aber trotzdem noch auf dem Schlauch.
Leider kommt immer noch eine Fehlermeldung (siehe Bild).
In der Tabelle t_auftrag_kalk gibt es folgende Felder:
KalkID =AutoWert
KalkNr=Integer ohne Duplikate (es soll immer der Wert Max+1) eingetragen werden
Auftragnr_kalk = double Duplikate möglich...
In der Tabelle t_kalkmaterial:
IDKalkmaterial=Autowert
FSKalkNrMaterial=Integer mit Duplikaten
auftragnr_kalk_m=double mit Duplikaten ...
Mein Code:
'--- tab.Artikel t_auftrag_kalk
strSQL = " INSERT INTO t_auftrag_kalk ( Kalknr, auftragnr_kalk, kundennr_kalk, kalkdatum, materialpreis_lager, materialpreis_sonstige, preis_leistung, Verzinkungskosten, FK_janein, FKSatz, Fixkosten, Multiplikator) " & _
" SELECT max(kalknr)+1, auftragnr_kalk, kundennr_kalk, kalkdatum, materialpreis_lager, materialpreis_sonstige, preis_leistung, Verzinkungskosten, FK_janein, FKSatz, Fixkosten, Multiplikator " & _
" FROM t_auftrag_kalk WHERE auftragnr_kalk = " & Me!auftragnr_kalk
db.Execute strSQL, dbFailOnError
lngArtIDNew = db.OpenRecordset("Select @@Identity")(0)
' '--- tab_Artikel_Material t_Kalkmaterial
strSQL = " INSERT INTO t_Kalkmaterial ( auftragnr_kalk_m, Artikelgruppe, Artikelnummer, Artikel, Dimension, VKEinheit, VKjeEinheit, MENGE, GesamtVK, Stueck, Laenge, Breite, kgProEinheit, verzinken, VerzBetrag ) " & _
" SELECT " & lngArtIDNew & " As FSKalkNrMaterial, auftragnr_kalk_m, Artikelgruppe, Artikelnummer, Artikel, Dimension, VKEinheit, VKjeEinheit, MENGE, GesamtVK, Stueck, Laenge, Breite, kgProEinheit, verzinken, VerzBetrag " & _
" FROM t_Kalkmaterial Where auftragnr_kalk_m = " & Me!Me!auftragnr_kalk
db.Execute strSQL, dbFailOnError
ich wäre dir sehr dankbar wenn du nochmals drüber schauen kannst.
Günther
Du hast hier zwei Probleme versammelt:
1) Du verwendest nicht den Primärschlüssel in den Tabellenverknüpfungen, sondern einen eigenen "beliebigen" Wert. Der Autowert erhöht sich selber und bedarf keiner Zusatzberechnung. Du hättest nicht das Folgeproblem.
Genau genommen bin ich erstaunt: In meiner Wahrnehmung benötigt man zur Erstellung einer Beziehung auf der einen Seite einen Primärschlüssel - was bei Dir nicht der Fall ist ...
2) SELECT max(kalknr)+1, ...
Ein bisschen so aggregieren geht so nicht.
Zitat3. Schritt: Gruppieren und Aggregation, GROUP BY-Abschnitt
Hier sollte am Rande bekannt sein, dass alle Felder im SELECT-Teil entweder im GROUP BY-Abschnitt enthalten sein müssen oder zu aggregieren sind (Bildung von Summen, Anzahlen, Durchschnitten, Maxima, Minima) oder einfach einen konstanten Inhalt aufweisen. Berechnete Ausdrücke aus solchen Feldern sind auch möglich.
Aus: Grundlagen - SQL ist leicht (11) - Reihenfolge der Abfrageabarbeitung (https://www.ms-office-forum.net/forum/showthread.php?t=353639)
In diesem Sinne müsstest Du also die gesamte Abfrage aufarbeiten, oder aber die kleine Berechnung durch eine komplette Unterabfrage ersetzen.
"...
SELECT
(SELECT max(kalknr) FROM t_auftrag_kalk WHERE auftragnr_kalk = " & Me!auftragnr_kalk & ") + 1,
auftragnr_kalk,
...
"(Die Zeilentrennung, die hier per VBA nötig wäre, habe ich aus Übersichtsgründen unterschlagen.)
Aber siehe 1): Ich würde davon abraten, eigene "kreative Wege" zu gehen und so Herausforderungen zu suchen, die andere nicht kennen. Die resultierende Einsamkeit müsstest Du durch eigene Fähigkeiten ausgleichen und diesen Kraftakt durchstehen => Probleme erzeugen oft Nachfolgeprobleme.
Hallo,
Wie Eberhard bereits schrieb, sind die Beziehungen über die PK
herzustellen.
Lade die DB mit wenigen Beispieldatensätzen hier hoch, dann schau
ich mir das an und mache einen Vorschlag.
gruss ekkehard
Hallo!
ZitatGenau genommen bin ich erstaunt: In meiner Wahrnehmung benötigt man zur Erstellung einer Beziehung auf der einen Seite einen Primärschlüssel - was bei Dir nicht der Fall ist ...
Es muss nicht unbedingt der PK sein, ein eindeutiger Index ist auch erlaubt.
LG
Josef
Hallo Josef,
Das ist wohl richtig, aber für eine Beziehung würde ich so ein
Feld trotzdem nicht verwenden.
gruss ekkehard
@ekkehard:
kommt immer auf das Vorhaben an. Ich nutze z. B. schon hin und wieder bewusst einen Mehr-Felder-PK und gebe dann aber für 1:n-Detailtabellen nur einen Autowert als FK-Wert weiter.
Im Datenmodell von #6 fällt mir auf, dass ein Kalk-Datensatz datentechnisch Kunde A und einen Auftrag von Kunde B enthalten könnte. .. Vielleicht braucht man die Kunden-Beziehung gar nicht in der Tabelle.
Sieht ein wenig nach einer Excel-Tabelle mit Ausfüllhilfen aus. ;)
Gruß
Josef
Vielen Dank für deine ausführlichen Erläuterungen. Ein großes Lob und vielen Dank, dass du immer so schnell und ausführlich antwortest. Auch allen anderen die sich einbringen vielen Dank. Ich stelle mir vor, dass du über meine Anfängerfehler oft nur lachen kannst. Aber ich muss mich erst so langsam in Access und speziell in VBA und SQL einlesen. Danke für den Link zu Grundlagen SQL.
Dass bei einer 1:n Verknüpfung immer der Primärschlüssel auf der einen Seite stehen muss war mir nicht klar. Wie aber Josef schreibt ist auch ein anderer eindeutiger Schlüssel (Long Integer indiziert ohne Duplikate möglich)!?
Ich werde aber meiner Datenbank diesbezüglich durchforsten. Das wird aber eine größere Baustelle. ::)
Auf den Vorschlag die Datenbank mit wenigen Datensätzen hochzuladen komme ich gerne noch zurück.
Nochmals vielen Dank
:D :)
Günther
Hallo,
@Josef Du bist ja auch in anderen Sphären unterwegs. Ich bevorzuge einen AutoWert als PK
um den ich mich nicht kümmern muss. "Schöne" Nummern (flfd. oder mit Buchstaben
oder Sonderzeichen) kann ich zur Anzeige oder Suche trotzdem verwenden.
@Günther
Unabhängig davon stimmen die Beziehungen aber auch noch nicht alle.
gruss ekkehard
Hallo!
@Günther:
Es gibt ein gutes Skript von Michael Zimmermann zum Thema "Normalisierung für Access-Entwickler" von der AEK7 auf den Download-Seiten der AEK unter http://www.donkarl.com/
Gruß
Josef
Zu der Diskussion unter euch Fachleuten noch eine Frage:
@JosefIch habe in der Tabelle Aufträge folgende Felder:
AuftragsID -Autowert =PK
Auftrag_nr - double (ohne Duplikate) - diese Zahl setzt sich aus Datum und Zeit der Auftragsanlage zusammen, Integer ist zu klein
...
mit der Auftrag_nr sind die Tabellen darunter verknüpft.(siehe Bild)
Mir wäre wichtig in den den Tabellen darunter die Auftrags_nr nicht die AuftragID mitzuführen da ich für den Import von Daten mich immer auf die eindeutige Auftrags_nr beziehen kann.
Ist dies für die Verknüpfung ein Problem oder wie du schreibst auch zulässig?
Bei der Kalkulation bin ich noch am Beheben der Redundanzen, da die Kundennr in der Kalk wirklich nicht gebraucht wird.
LG Günther
Hallo,
Zitatdiese Zahl setzt sich aus Datum und Zeit der Auftragsanlage
Das ist ja sonst nichts als die Uhrzeit mit DAtum. Das ist der DAtentyp "Datum/Uhrzeit" automatisch. Und das ist im Hintergrund eine Zahl des Typs Double. Es ist ja auch sonst nichts als ein Zeitstempel der mit Now() direkt gesetzt werden kann.
Zitatmit der Auftrag_nr sind die Tabellen darunter verknüpft.(siehe Bild)
Die Auftrag_nr ist eine Double Zahl (Fließkomma) das taugt nicht als Schlüsselfeld.
Verwende die AuftragID als Fremdschlüssel. Das gilt für alle Beziehungen über die Auftrag_nr.
Und wenn die Auftrags_nr für den Import notwendig ist, so kommt die aus einem anderen System und da ist nicht sichergestellt, dass es die gleiche Auftrag_nr auch bei den Aufträgen gibt, es ist ja wie gesagt Fließkomma. Das musst Du ändern.
Bei den Beziehungen ist im Regelfall der Typ 1 einzustellen. Das wird nur bei Bedarf in den Abfragen (dort sind es Verknüpfungen) geändert.
Ich glaube nicht, dass das Datenmodell so stimmt. Du solltest mal das ganze Beziehungsbild hier zeigen und zwar so, dass man alle Felder der TAbellen sieht. Die Felder mit den TAbellen lassen sich größer ziehen.
Danke für deine Ausführungen. Ich bin dabei noch einige Redundanzen (zB berechnete Felder)zu entfernen, dann lade ich das Beziehungsbild hoch.
Beim Bearbeiten der Datenbank haben sich folgende Fragen ergeben.
1) Macht es Sinn eine Tabelle in zwei Teile zu zerlegen? (1:1) Beziehung um die Anzahl der Felder in einer Tabelle zu reduzieren.
2) Die Materialeingabe zb in der Kalkulation erfolgt über ein Unterformular (siehe Bild). Derzeit speichere ich beim Verlassen der Dimension die Artikelnummer ab. Die Artikelgruppe, Artikel und Dimension dienen der Suche des Artikels. Derzeit speichere ich aber auch diese drei Felder mit. Könnte ich aber über die Artikelnummer wieder abfragen. Ist das in dieser Form sinnvoll, oder wie schaut hier eine bessere Variante aus um nicht Felder die abgefragt werden können mitzuspeichern. Die Felder müssen aber im Unterformular sichtbar bleiben.
Günther
Hallo,
Zitat1) Macht es Sinn eine Tabelle in zwei Teile zu zerlegen? (1:1) Beziehung um die Anzahl der Felder in einer Tabelle zu reduzieren.
Wenn dieser Wunsch besteht hat man mit ziemlicher Sicherheit schon was falsch gemacht. Bei einer korrekt aufgebauten Datenbank sind im Regelfall nicht sehr viele Felder in einer Tabelle.
Ich würde z.B. denken, 30 Felder sind schon zu viel.
Ich habe erhebliche Zweifel, dass das so stimmt. Im Ufo gibt es z.B. eine Artikelgruppe, das ist aber eine Eigenschaft des Artikels und hat somit im Ufo nichts verloren. Schon gar nicht zur Auswahl. Ausgewählt muss der Artikel werden. Sind Hafo und Ufo verknüpft ? Wenn ja, über welche Felder ?
Für weitere Ratschläge wird das Beziehungsbild benötigt.
Zitat... und zwar so, dass man alle Felder der Tabellen sieht. Die Felder mit den Tabellen lassen sich größer ziehen.
Hallo Günther,
Zitat1) Macht es Sinn eine Tabelle in zwei Teile zu zerlegen? (1:1) Beziehung
Wie Klaus schon schrieb, eher nicht.
Für mich machen 1:1-Beziehungen Sinn, wenn es eine typisierte Hauptentität gibt und
die Typen abweichende Eigenschaften haben (z.B. Personen -> Hersteller, Lieferanten,
Kunden, Mitarbeiter).
gruss ekkehard
Ich staune immer wieder, wie schnell ich in diesem Forum Antworten bekomme. Vielen Dank, wirklich toll.
Zu deinen Zweifeln mit dem Unterformular:
Die Felder dienen der einfachen Suche von Artikeln. Im ersten Feld sind die Artikelgruppen, im zweiten die Artikel, im dritten die Dimension des Artikels. So lassen sich aus der großen Anzahl der Artikel sehr schnell die richtigen Artikel suchen/auswählen. Nach der Auswahl der Dimension kann die Artikelnummer gespeichert werden. (Siehe Bild Artikelsuche).
In der Anlage auch das Beziehungsbild damit du dir vorstellen kannst woran ich derzeit arbeite. Die Tabelle t_auftraege hat ca. 30 Felder. Meine Überlegung war die im Bild rot markierten Felder in eine eigene Tabelle auszugliedern, da diese den Status des Auftrages betreffen.
Günther
Hallo,
zu den Beziehungen bzw. der Tabellenstruktur könnte man Romane schreiben, so viel gibt es da anzumerken.
Ich fange mal von Links nach rechts an, ohne Anspruch auf Vollständigkeit.
- Wie in vielen Tabellen wurde ein Primärschlüssel angelegt der aber nicht genutzt wird.
Dann kannst Du auch das PS Feld löschen und das Feld für die Beziehung zum PS machen.
- Summenfelder braucht es nicht in den Tabellen
- Bei den Kundenstammdaten sind die Felder für die Kommunikation als n:m Beziehung auszulagern, dazu ist auch eine Tabelle für die Kommunikationsart erforderlich.
- Die Adressen eines Kunden sind auszulagern (mit einer extra Tabelle für PLZ und Ort) mit einem Kennzeichenfeld für die Art der Adresse (Hausanschrift, Lieferanschrift, Rechnungsanschrift etc.)
- Beim Artikel gibt es den Primärschlüssel IDArtikel und gleichzeitig ein Feld ID das für die Beziehung genutzt wird. Warum machst Du dann dieses Feld nicht zum PS .
- Das gleiche gilt sinngemäß für die Tabelle Auftraege.
- Was soll das ReDatum in der Tabelle für die Auftraege ?
- In der Tabelle für die Angestellten ist das PS Feld AngID, das Fremdschlüsselfeld nennt sich dann ArbeiterID, das ist doch verwirrend. Abgesehen davon ist rein formal ein Unterschied zwischen Angestellten und Arbeitern.
- Die Tabelle für die Mahnungen ist falsch. Du brauchst eine Tabelle für die Mahnungsstufen (mit dem unterschiedlichen Mahnungstext) und eine Tabelle zur Zuordung der Mahnstufen zur Rechnung.
- Die Tabelle für die Zeiterfassung ist falsch und unlogisch. Da steht ein Datum drin, gleichzeitig wird auf einen Wochentag bezogen, das Datum legt aber den Wochentag schon fest. Außerdem würde man die Wochentagsfelder nicht für jeden Wochentag erfassen, sondern nur die 4 Zeitfelder mit einem zusätzlichen Feld für den Wochtag als Zahl (1=Mo). Die AZ.. Felder entfallen ersatzlos. Die AZ wird errechnet.
- Die Tabelle auftrag ist völlig unübersichtlich. Mir scheint, das ist die Rechnung. Das mit den Teilrechnungen kann so auch nicht funktionieren. Es kann ja mehr als eine Teilrechnung geben.
- Die Rechnungsanschrift sollte nur ein Fremdschlüssel sein zur Adressentabelle.
Die Rechnungen sind daher auszulagern als jeweisl ein Datensatz (Teilrechnung 1, Teilrechnung 2, Schlussrechnung. Die Mahnungen müssen dann mit der neuen Rechnungstabelle in Beziehung gesetzt werden, denn jede (Teil)Rechnung kann für sich extra gemahnt werden.
- Wieso gibt es in der TAbelle für die Stunden AZStunden und AzMinuten ?
- In dieser Tabelle gibt es auch eine ArbeiterID aber keine Beziehung
- Es gibt eine Beziehung ohne RI
- Bei den Beziehungen ist in der Regel immer der Typ 1 einzustellen. Das wird bei Bedarf nur in den Verknüpfungen der Abfragen geändert.
Alles in allem finde ich das Datenmodell überladen und unstrukturiert. Da würde ich noch mal von vorn anfangen.
Vielen Dank für die rasche und ausführliche Analyse. Für mich heißt das zurück zum Start und die ganze Datenbank neu aufbauen.
Vor ich damit starte noch folgende Fragen:
Ich bin bisher davon ausgegangen, dass es beim Primärschlüssel immer ein Autowert sein sollte. Da dies aber für die Auftragsnummer aufgrund der Länge nicht geht (die Auftragsnummer wird so gebildet << Me.Auftrag_Nr_h = Format(Date, "yymmdd") & Format(Time, "hhmm")>>, habe ich vor die Auftragsnummer eine AuftragsID als Autowert gestellt. Da diese aber wie du richtig schreibst nicht als PS verwendet wird, macht es keinen Sinn.
Nachdem ich mir einige Videos zu den Verknüpfungen angeschaut habe, bzw. in Skripten gelesen habe kann diese Auftragsnummer in der 1:n Beziehung auch als PS verwendet werden.
Das müsste doch zB auch bei der Kundennummer funktionieren wenn ich diese als Primärschlüssel verwende und indiziert ohne Duplikate bei jeder neuen Kundennummer +1 generiere.
Bei der Übernahme in die neu zu konzipierende Datenbank funktioniert meiner Meinung nach der Autowert nicht, da sich zB Auftragsnummer und Kundennummer ja nicht ändern dürfen.
Bin ich da richtig?
Günther
Hallo,
@klausManno Mann, das grenzt ja schon an Arbeit (Jobbörse).
Grosses Lob von dritter Seite; - bei solchen Bildern fange ich gar nicht
erst an mir Gedanken zu machen. Ich frage mich immer wie man da als
Entwickler (der der Einzige hier ist, der seine Realität kennt) mit sowas
arbeiten kann.
@Günther
ZitatIch bin bisher davon ausgegangen, dass es beim Primärschlüssel immer ein Autowert sein sollte.
Ist halt das bequemste, s. #8-#11.
Zitatabe ich vor die Auftragsnummer eine AuftragsID als Autowert gestellt.
Na also, geht doch.
ZitatDa diese aber wie du richtig schreibst nicht als PS verwendet wird, macht es keinen Sinn.
Dann mach sie zum PK.
ZitatAuftragsnummer in der 1:n Beziehung auch als PS verwendet werden.
Kann Ja,
sollte aber nicht, s. wieder #8-#11; - gilt auch für die KundenNr.
ZitatBei der Übernahme in die neu zu konzipierende Datenbank
Was heisst das? Der Import der jetzigen Daten in das endgültige Datenmodell?
Das geht schrittweise,
- Import der Aufträge, dabei wird die ID (AutoWert) neu vergeben
- Import der abhängigen Tabellen mit dem "alten" FS
- Überschreiben des alten FS mit der neuen ID (Verknüpfung über den alten PK)
Deine eigenen Nummern (jetzt PS) in den Stammtabellen ändern sich dabei ja nicht, nur
die FS.
gruss ekkehard
Hallo,
Zitatdie Auftragsnummer wird so gebildet << Me.Auftrag_Nr_h = Format(Date, "yymmdd") & Format(Time, "hhmm")>>
Das ist doch sonst nix wie Datum und Uhrzeit. Das geht so:
Me.Auftrag_Nr_h = Format(Now, "yymmddhhnn")Das Kürzel für die Minuten ist nn, nicht mm, mm sind die Monate.
Ein solches Feld ist aber (wegen Format) ein Textfeld und daher als PS nicht so geeignet.
Diese Auftragsnummer gibt es nur in einer einzigen Tabelle, nämlich im Auftrag.
In vom Auftrag abhängigen Tabellen braucht man dann ein extra Feld für den Fremdschlüssel undd as ist eine Zahl (Longinteger) die mit der AuftragsID (dem Autowert) in Beziehung gesetzt wird.
Welchen Wert der Autowert hat ist dabei völlig bedeutungslos, der ist im Regelfall gar nicht sichtbar.
Die Kundennummer kann (in der Kundentabelle !!) extra geführt werden.
Grundregel:
Beziehungen laufen im Regelfall über den Autowert und ein Feld (Longinteger) in abhängigen Tabellen.
Also, im Auftrag gibt es ein Fremdschlüsselfeld zum Autowert (der ID) des Kunden. Im Auftrag selbst gibt es die Kundennummer nicht. Und wie gesagt, Beziehungen immer Typ1.
In Abfragen sind die Linien dann keine Beziehungen mehr, sondern Verknüpfungen, die Verknüpfungen können (müssen aber nicht) sich von den Beziehungen unterscheiden. Und in Abfragen kann dann auch der Beziehungstyp eingestellt werden (INNER-, LEFT-, RIGHT JOIN).
ZitatBei der Übernahme in die neu zu konzipierende Datenbank funktioniert meiner Meinung nach der Autowert nicht, da sich zB Auftragsnummer und Kundennummer ja nicht ändern dürfen.
Doch, da musst Du aber etwas Aufwand betreiben und mit Aktualisierungsabfragen die Daten aktualisieren. Z.B. die Verknüpfungen in den Abfragebn so anlegen wie das jetzt ist und dann die Autowerte in den Fremdschlüsselfeldern aktualiseren. Die alten Fremdschlüsselfelder sind dann zu löschen.
Immer an einer Kopie der Datenbank testen.Und noch ein Hinweis:
Access mus man lernen und da kann man sich auch nicht an Excel orientieren.
Access ist kein Anwenderprgramm (wie Word oder Excel) sondern eine Programm zum Entwickeln relationaler Datenbanken. Die fertige Datenbank ist dann erst das Anwenderprogramm.
ZitatNachdem ich mir einige Videos zu den Verknüpfungen angeschaut habe,
Von Videos zu Access halte ich nicht viel, ich habe bisher nur wenige gesehen an denen ich nichts zu mecken hätte.
Hier mal ein Link zu den theoretischen Grundlagen:
https://www.hdm-stuttgart.de/~riekert/lehre/db-kelz/
Und hier noch etwas mehr aus der Praxis:
https://www.access-tutorial.de/
Danke für eure Tipps. Ich weiß jetzt so ungefähr wo die Reise hingeht.
@ekkehard zu
Ich frage mich immer wie man da als
Entwickler (der der Einzige hier ist, der seine Realität kennt) mit sowas
arbeiten kann.
Ich habe die Datenbank so übernommen und mich noch nicht getraut das Ganze neu aufzubauen, da ich mich mit Access noch nicht so gut auskenne. Eure Tipps haben mich aber ermutigt die gesamte Datenbank neu aufzubauen und dabei die Grundsätze der Normalisierung und der Vermeidung von Redundanzen einzuhalten.
@klaus Ein ganz besonderes Danke und Lob, dass du dich mit der Tabellenstruktur so intensiv auseinandergesetzt hast.
Ich werde das Beziehungsbild hochladen wenn ich den ersten Teil umgesetzt habe. Ich hoffe, dass ich dann alles so umgesetzt habe wie du es mir in deiner ausführlichen Darstellung beschrieben hast.
Gruß Günther
Hallo Günther,
ZitatIch habe die Datenbank so übernommen und mich noch nicht getraut das Ganze neu aufzubauen,
Bevor ich damit anfange räume ich aber erstmal das Beziehungsfenster auf um einen
Überblick zu bekommen.
gruss ekkehard
Hallo Klaus,
ich habe nach deiner ausführlichen Beschreibung begonnen die Datenbank neu aufzusetzen. (Siehe Bild)
Folgende Fragen sind aufgetaucht:
1) Bei der tblKommunikationsart ist mir die n:m Beziehung nicht klar - derzeit ist es bei mir nur eine Teilung der tblKunden.
2) Ist es sinnvoll alle Verknüpfungen mit Aktuelisierungs- und Löschweitergabe zu erstellen?
3) Bei sehr kleinen Tabellen zB tblAnrede könnte auch mit dem Nachschlags Assistent gearbeitet werden
ID_AkadGradAlt AkadGradAlt
1 Ing.
2 Dipl. Ing.
3 Mag.
4 Mag.(FH)
5 Dr.
6 Dkfm.
7 Dipl. Vw
Nachteil sehe ich, dass Ergänzungen vom Anwender nicht gemacht werden können. Ist es ein Problem in einer Datenbank mit so vielen Tabellen zu arbeiten?
LG Günther
Hallo,
die Tabelle "tblKommunikationsart" ist falsch. Die Arten sind keine Feldnamen, sondern Datensätze und die Art ist Feldinhalt.
Dann braucht es noch eine Tabelle zur Zuordnung der Art zum Kunden. Also FS zum Kunden und FS zur Art, erst dann hast Du eine n:m Beziehung.
ZitatIst es sinnvoll alle Verknüpfungen mit Aktuelisierungs- und Löschweitergabe zu erstellen?
Ja, ist meistens sinnvoll.
Weiterhin:
- Der Auftrag hat keine Beziehung zum Kunden.
- Wieso gibt es 2 Tabellen für den akad.Grad ?
- Auf den Nachschageassi würde ich auch bei kleinen Tabellen verzichten.
- Was ist mit einer Tabelle für die Rechnungen ?
ZitatNachteil sehe ich, dass Ergänzungen vom Anwender nicht gemacht werden können.
Über VBA kannst Du programmieren, dass auch der Anwender Ergänzungen machen kann.
ZitatIst es ein Problem in einer Datenbank mit so vielen Tabellen zu arbeiten?
Das Datenmodell muss stimmen, die Anzahl der Tabellen ist dabei relativ bedeutungslos.
Hallo,
vielen Dank für deine rasche und fachliche Antwort.
Wie die tblKommunikationsart aussehen soll ist mir noch nicht klar. Vielleicht kannst du mir ein Bild übermitteln wie das aussehen kann.
Bei den Verknüpfungen stelle ich also grundsätzlich Aktualisierungs und Löschweitergabe ein.
Beziehung zwischen Auftrag und Kunde habe ich hergestellt (zeigt mir wie genau du dir das Beziehungsbild anschaust, super - großes Lob!!)
2 Tabellen für den akad. Grad gibt es da die alten akad. Grade(Mag....) in der Adresse vor dem Namen die neuen akad. Grade (BEd...) hinter dem Namen stehen (Önorm 1080),
Die restlichen Tabellen (Rechnung...) bin ich am überarbeiten.
Gruß Günther
Hallo Günter,
Na also,sieht doch gleich viel besser aus. Wenn du jetzt noch die Tabellen, die
mit den Arbeitnehmern nach rechts und die Kunden etwas nach unten schiebst, hast
du ein übersichtliches Bild, mit dem man arbeiten kann.
Die fehlende Beziehung zwischen Kunden und Aufträgen hat Klaus schon aufgezeigt.
Was mir noch auffällt, - die beiden FS Anschrift und Kom.-Art braucht es in der
Kundentabelle nicht, die Beziehung läuft ja andersherum.
Die Tabelle Kom.-Arten sieht im Prinzip genauso aus wie die "tblAnschriftArten".
Den Rest hat Klaus beschrieben.
@klausZitatJa, ist meistens sinnvoll.
Da habe ich schon anderes gelesen. Eine Aktualisierung ist nur sinnvoll, wenn man
als PK keinen AutoWert verwendet. Über eine Löschweitergabe sollte man wirklich
bei jeder Beziehung genau drüber nachdenken. Da man ja auch einmal gültige DS eh
nicht löschen sollte, setze ich die eigentlich nur während der Entwicklungszeit um
Testdaten in verbundenen Tabellen mit einer Abfrage zu löschen.
gruss ekkehard
Ich war jetzt einige Zeit mit anderen Dingen beschäftigt. Jetzt möchte ich die Datenbank weiter bearbeiten.
Die Aktualisierungsweitergabe setze ich laufend ein. Die Löschabfrage nur für die Entwicklung da sonst ev. versehentlich Adressen gelöscht werden.
In der Anlag nochmals das Beziehungsbild. Bei den Kunden ist mir die Tabelle Kommunikationsart noch nicht klar. Bisher habe ich in der Tabelle Kunden eine Feld für Handy, EMail,... gehabt. Welchen Vorteil bringt die eigene Tabelle Kommunikationsart? Oder habe ich hier noch etwas nicht verstanden?
Alle Felder mit der Bezeichnung FS_ enthalten dann nur die Zahl des PS der Haupttabelle. Heißt aber dann für alle Formulare und Berichte müssen die Tabellen mit den FS mit eingezogen werden.
Bin ich so auf dem richtigen Weg?
Vielen Dank für eure Unterstützung!
LG Günther
Hallo,
ZitatWelchen Vorteil bringt die eigene Tabelle Kommunikationsart?
Das du einem Kunden beliebig viele Kommunikationsadressen *) auch gleicher
Art zuordnen kannst.
*) Diese Tabelle fehlt dir. Der Aufbau läuft so
Kunden:
PK = KundenID
KommArten:
PK = KommArtID (Autowert)
Bezeichnung (Tel, Fax, Email usw.)
KommAdressen:
PK = AdressID (Autowert)
FK = KundenID_F
FK = KommArtID_F
KommAdresse = Text (die eigentliche Adresse; Tel, Fax, Email usw.)
ZitatHeißt aber dann für alle Formulare und Berichte müssen die Tabellen mit den FS mit eingezogen werden.
Ja, aber wo ist das Problem?
KommAdressen ist ein UFo im HFo Kunden.
KommArten wird da (im UFo) als Kombi zur Verfügung gestellt.
gruss ekkehard
Vielen Dank für die rasche Rückmeldung und die genauen Hinweise bez. Kommunikationsart.
Jetzt habe ich es endlich kapiert.
Deine Schreibweise ....ID_F habe ich übernommen, finde ich übersichtlicher. Ich hoffe das geht in Ordnung.
Vielen Dank!
LG Günther
ZitatIch hoffe das geht in Ordnung.
Na klar, wird hier doch sogar von mehreren der Regulars immer wieder
vorgeschlagen.