Office: (Office 2003) Logik für Datenerfassung / Gültigkeitsprüfung

Hallo Peter

Vielen Dank. Es ist mir jetzt klar wie das geht.

Kleine Nebenfrage: setzt du die Tabellen bewusst nicht in Beziehungen zueinander, wie ich das hatte (1:n) und verwendest stattdessen Abfragen? Oder wie muss ich das interpretieren?

Gruss
Santo

 

Hallo,

die Beziehungen hatte ich gelöscht, da PLZ Primärschlüssel war!. gleichzeitig habe ich PLZ als Text umgewandelt, da es in Deutschland PLZ - Zahlen wie 0977.. gibt. Solche PLZ können nur mit Text dargestellt werden (führende Null); aber scheinbar gibt es das nur in Deutschland!

Formulare sollten als Datenherkunft stets Abfragen haben!; deshalb die Einführung von qryPersonal.

Ansonsten: Objektnamen (Tabellen u. Feldnamen) kurz halten, auf Leerstellen u. Sonderzeichen (außer _ ) verzichten.


Gruß Peter

 

Hallo Peter

Wo ist das Problem, wenn die PLZ Primärschlüssel war, das war ja - dachte ich jedenfalls immer - genau zwingend damit ich diese Verknüpfung machen konnte (1-n) zur Personalstamm Tabelle.

Versteh nicht, was daran schlecht war? Kannst du mir das kurz erläutern - ich hatte drum mal eine Meldung, dass der Datensatz nicht geschrieben werden konnte, weil keine Beziehung bestehe... deshalb habe ich das auch so mit den verknüpfungen versucht.

Gruss
Santo

 

Hallo santo,

das ist nicht nur schlecht, sondern falsch*wink.gif*

Ein Primärschlüssel kann in einer Tabelle nur einen Wert haben.
Es gibt aber auch in der Schweiz mehrere Orte mit gleicher PLZ!!!!

Von diesen Orten könnte dann jeweils nur ein Ort in die Tabelle aufgenommen werden, da 2 gleiche PLZ nicht möglich sind, wenn PLZ Primärschlüssel ist.

Gruß Peter

 

Hallo,
Es Code:

Genau wie in Deutschland auch.
Daher erhält auch die PLZ Tabelle einen Autowert als Primärschlüssel. In der Personalstamm Tabelle wird dann der PLZ Schlüssel gespeichert und nicht die PLZ. Dann kann wieder eine ganz normale 1:n Beziehung eingerichtet werden.

 

Hallo santo,

anbei die db mit den nun richtigen Beziehungen!

Gruß Peter

 

Hallo,
wenn man in die Abfrage für das Formular noch die Tabelle mit den Ortschaften aufnimmt, braucht das Kombi (PS_Ortschaft_Nr) keinen Code mehr, dann aktualisiert sich das Formular automatisch.

 

Da ist noch etwas nicht in Ordnung:
in der Tabelle Ortschaften steht jeweils der Kanton. Da aber ein Kanton viele Ortschaften umfasst, müssen die Kantone in eine separate Tabelle und dann nur die Kantons-Id dem Ort zugewiesen werden.
Außerdem muß in der Tabelle Orte ein zusammengesetzter Index über "Ort" und "PLZ" gelegt werden.
Die 4 Sprachen der Schweiz "nebeneinander" aufzuführen ist grenzwertig. Du kannst davon ausgehen, daß in der Schweiz immer jeder Kanton in jeder Sprache eine Bezeichnung hat und auch, daß sich diese Sprachen nicht ändern. Was ist aber mit Ausländern? Brauchst Du die Info, ob etwa ein deutscher Mitarbeiter aus Baden-Würstchenberg kommt?

 

Hallo,

das ganze kommt daher, dass wir immer nur schrittweise ein Problem lösen anstatt alle Probleme wie schon mehrfach angesprochen gleichzeitig zu lösen versuchen.

Das mit den Kantons muss santo entscheiden.

das ist wohl wahr; zugleich könnten PS_PLZ u. PS_Kanton beide aus der Tabelle tblPersonalStamm entfernt werden u. nur PS_Ortschaft_Nr gespeichert werden.
Dann in Abfrage des Formulars beide Felder aus Tabelle tblOrtschaften zufügen (wie gpswanderer vorschlägt) u. es ist kein Code im Formular zur Erfassung des Ortes mehr nötig u. die Tabelle ist auch normalisiert.


@santo: Sicher hat deine DB noch mehr Probleme, wie wäre es mit einer Gesamtdarstellung aller Tabellen u. Felder sowie deren Darstellungen in Formulare?

dann könnten wir das häppchenweise Probieren beenden*Smilie

Gruß Peter

 

Santo, schau nochmal in Beitrg #18. Du brauchst 'nen Bleistift und ein Stück Papier, um aufzuschreiben, welche Daten gespeichert werden sollen und welche Fragen Dir die DB nachher beantworten soll.
Dann brauchst Du einen normalisierten Tabellenaufbau und dann kommen die Formulare.

Entweder ist es totsicher, daß alle Mitarbeiter immer und ausschließlich aus der Schweiz kommen oder sie können aus jedem beliebigen Land kommen oder die Information ist für deinen Zweck nicht wichtig.
Wenn Du die Frage durchdacht hast, weißt Du, welche Tabellen für dieses Teilproblem erforderlich sind.

 

Hallo zusammen

Das war mir jetzt so nicht bekannt, dass in der CH mehrere Orte mit der gleichen PLZ bedient werden -aber wenn dem so ist, klar, dann ist ein konkatenierter Index aus Ort und PLZ notwendig.

Es ist tatsächlich so, dass Personen auch aus anderen Ländern kommen können, und es ist dabei ist nur nur entscheiden, in welchem Land sie ihren Lebensmittelpunkt (Wohnung & Familie) haben, sondern auch ihre Nationalität (z.B. Mitglied der EU) und ob sie in dem Land, in welchem sie wohnen auch noch arbeiten oder ob sie nur in CH arbeiten oder zusätzlich noch in anderen Ländern, aber nicht ihrem Wohnsitzland (wegen Quellensteuerfragen und Sozialversicherungsfragen).

Bleisstift und Papier ist sicher eine gute Idee - allerdings wäre wohl ein Buch über rel.DB auch angebracht - das Thema ist einfach zu lange her und nie mehr gebraucht.

Tja, habe echt gedacht, das wäre ein kleines Projekt....


Gruss
Santo

 

Ich hab' Dir mal als Hilfestellung ein paar Tabellen aufgebaut. Der Teufel steckt im Detail.
Beispiele:
Wenn es nur einen Lebensmittelpunkt gibt, kann man den mit in die Personentabelle stecken und gut ist. Wenn es 2 oder mehr LeMiPus geben kann, dann braucht's eine separate Tabelle. Die Frage könnte Dir in Deutschland vielleicht ein Steuerberater beantworten; wie die Gesetzeslage in der Schweiz ist? Ich nix weiß.
Selbst die Nationen sind nicht so klar, wie es bei oberflächlicher Betrachtung scheint. Die Kanarischen Inseln gehören politisch zu Spanien, Spanien gehört zur EU. Klare Sache. Pustekuchen: in Bezug auf die Umsatzsteuer werden die Kanarischen Inseln wie Nicht-EU-Länder behandelt!
Als Schweizer kennst Du sicher den eigentümlichen Status von Büdingen; das sind die mit den 2 PLZ, einmal nach schweizerischem und einmal nach deutschem Modell.
Man könnte jetzt die Sache bis zum Erbrechen normalisieren und eine weitere separate Zuordnungstabelle schaffen, nur um Büdingen unterzubringen. In solchen seltenen Spezialfällen reicht aber vielleicht auch ein Hinweis in der PLZ-Tabelle oder eine Tabelle mit allen Sonderstatus-PLZ.

Gerade bei Dingen, die der politischen Beurteilung unterliegen, muß man immer auf Änderungen und zum Teil völlig bescheuerte Ausnahmen gefasst sein. Da hilft nur super-saubere Datenerfassung um bei allfälligen Änderungen mit möglichst wenig Handarbeit die Logik der DB anpassen zu können.
Also beachten wir die Regel: data remains, code not!
Trenne die Datenerfassung (Tabellen) strikt von der Datenverarbeitung (VBA)!

Übrigens würde ich die Sache gleich so aufbauen, daß man alle Adressen erfassen kann. Ob eine der Personen ein Mitarbeiter ist, geht einfach aus einem Eintrag in einer separaten Tabelle hervor.

Viel Spaß beim Knobeln.

Edit:
Ich habe Büdingen und Büsingen verwechselt.