Office: (Office 2013) VBA, Formulare, Verknüpfungen

Hallo,

nein, muss sie nicht. Die Zusammenhänge (Beziehungen) werden nur über die Schlüsselfelder (Autowert > Zahl) gesteuert, das reicht und ist richtig.

Genau so ist es, das ist ja der Sinn der extra Schlüsselfelder.
Mit Abfragen und den angelegten Verknüpfungen) hast Du alle Felder aus den beteiligten Tabellen zur Anzeige zur Verfügung.

 

Ok, Verstehe, kein Wunder das technisch-denkenden Entwickler gewisse Ideen von mir für überflüssig halten. Man lernt eben ... *redface

 

Die Primärschlüssel als Autowerte zu definieren hat den entscheidenden Vorteil, dass sie automatisch vom System generiert werden und für jeden Datensatz eindeutig sind. Eine darüber erzeugte Verknüpfung ebenso.

Wenn du eine deiner anderweitig bestimmten und an äußere Bedingungen geknüpften Nummern verwendest, hast du schon ein Problem(chen), wenn sich eine solche Nummer mal ändert. Sag nicht, das wird nie vorkommen *wink.gif* .

Irgendwann kommt der Chef bestimmt auf die Idee, 601 wäre eine viel bessere Kennzeichnung der Kategorie als 303 - dazu fühlen sich Chefs verpflichtet, schon wegen der Existenzberechtigung als Entscheider *biggrin.gif* .

Und dann darfst du in sämtlichen verbundenen Tabellen, Abfragen und Berichten den Käse ändern. Mit dem Autowert-PK änderst du das genau ein Mal in der Kategorientabelle.

maike

 

Hallo!

[etwas OT, da nicht zum Thema Maskengestaltung passend]

Ich will hier keine Grundsatzdiskussion vom Zaun brechen, trotzdem eine Anmerkung:

nein, muss sie nicht. Die Zusammenhänge (Beziehungen) werden nur über die Schlüsselfelder (Autowert > Zahl) gesteuert, das reicht und ist richtig.

Wenn Kategorien eindeutige Kennungen haben, würde ich durchaus überlegen diese als PK zu verwenden und keinen Autowert. Eventuell ist auch ein vorgebener Zahlen-PK besser als ein Autowert geeignet.
Autowert ist gut und praktisch, wenn man aus den Daten keinen eindeutigen (und "stabilen") Schlüssel ableiten kann.

Wenn man einen Autowert und einen eindeutigen Kategorien-Code in einer Tabelle hat, ist der Autowert nur Balast, da für die Anzeige des Codes ein Lookup in die Kategorien-Tabelle erforderlich wird.

Autowert ist grundsätzlich gut, aber man muss es damit auch nicht übertreiben. Ich selbst verwende den sehr oft - aber eben nicht immer.
Ich lese aus den obigen Beiträgen irgendwie heraus "nimm immer einen Autowert - alles andere ist falsch". Dem wollte ich widersprechen bzw. etwas einschränken. *Smilie

Michael Zimmermann zeigte die Konzepte für PK, Indizes usw. in der AEK 8. Die Vortragsunterlagen sind im AEK-Download abzuholen.

Dafür gibt des die Aktualisierungsweitergabe bei der RI. *wink.gif*
Bezüglich Berichte: wenn in der Datenquelle der Berichte statisch nach der Kategorie gefiltert wird, finde ich einen Filter auf einen Autowert auch nicht besser. Da muss man nämlich dafür sorgen, dass im Entwicklungs-, Test- und Produktiv-System immer die identischen Autowerte existieren. => Statisch vorgebener PK wäre in so einem Fall besser. Das muss aber nicht der Kategoriename sein, es könnte auch ein vom DB-Entwickler vorgebener Code oder Zahl sein.

mfg
Josef

 

Hallo,
@josef

Grundsätzlich ist man ja der Auffassung alphanummerische PS sind weniger geeignet als reine Zahlenschlüssel (entnehme ich vielen Forenbeiträgen), wie sieht es damit aus Deiner Sicht aus ?

 

Hallo Klaus!

Zahlen-Schlüssel sind schneller, da Zahlen schneller im Index gefunden werden.

Ich zeige einfach einmal ein Beispiel (aus einem meiner Projekte), was ich meinte:

Variante 1 ("Code" ist PK)
tWorkPackages
- idWorkPackage ... int, identity(1, 1), PK
- fiProject .. int, FK zu idProject in tProjects (idProject ist wieder ein Autowert)
- fiParentWP .. int, FK zu idWorkPackage
- fiWorkPackageType ... varchar(5), FK zu idWorkPackageType in tWorkPackageTypes
- ...

tWorkPackageTypes
- idWorkPackageType varchar(5), PK
- WorkPackageTypeName varchar(255)
- ...


In idWorkPackageType stehen Codes, die den Anwendern bereits klar ersichtlich machen, um welche Art von Arbeitspaket es sich handelt.

Ausgabe in der Übersichtsliste für die Arbeitspakete (ohne Filter auf WorkPackageCode):
Code:

=> Zugriff auf tWorkPackageTypes-Tabelle wird nicht benötigt


Variante 2 (Autowert für Typ)
tWorkPackages
- idWorkPackage ... int, identity(1, 1), PK
- fiProject .. int, FK zu idProject in tProjects (idProject ist wieder ein Autowert)
- fiParentWP .. int, FK zu idWorkPackage
- fiWorkPackageType ... int, FK zu idWorkPackageType in tWorkPackageTypes
- ...

tWorkPackageTypes
- idWorkPackageType int, identity, PK
- WorkPackageCode varchar(5), Unique Index
- WorkPackageTypeName varchar(255)
- ...

Ausgabe in der Übersichtsliste für die Arbeitspakete (ohne Filter auf WorkPackageCode bzw. fiWorkPackageType):
Code:

=> Index-Seek in tWorkPackageTypes ist erforderlich (der läuft zwar bestimmt schnell, aber nicht so schnell, als würde es ihn nicht geben).

Was ist beim Daten-Filtern:
Es besteht im Formular die Möglichkeit nach dem Typ zu filtern.
In so einem Fall erfolgt eine Text-Suche im Index-Feld. Das ist bestimmt langsamer als eine Zahlensuche, wenn man in der Filter-Maske den Typ mittels Dropdown auswählt und dann die daraus ermittelte ID-Zahl als Filter weitergibt.
=> Ich wette aber, dass die User diese langsamere Filterung nicht merken werden. *wink.gif*
Anm.: eine Textsuche in der tWorkPackageTypes-Tabelle nach WorkPackageCode um die passenden Arbeitspakete zu erhalten, wäre in so einem Fall auf jeden Fall langsamer als in Variante 1 - aber das würde man dann nie so gestalten.

Vor allem muss man bedenken, dass das nicht der einzige Filter sein wird.


Bearbeitungsmaske:
In der Bearbeitungsmaske gibt es ein Dropdown zum Auswählen des Types.
Die Datenherkunft des Dropdowns fülle ich aber erst, wenn der Anwender den Fokus in die Combobox setzt. Für die Anzeige benötigte ich keine gefüllte Combobox, da der für die Anwender verständliche Wert bereits in der Arbeitspaket-Tabelle steht. => Ich benötigte keinen extra Zugriff auf eine Server-Tabelle, was beim Laden des Formulars hilft.

Zur Sicherheit noch einmal erwähnt: ich habe nichts gegen Autowert-Felder. Ich will nur darauf hinweisen, dass sie nicht zwingend sein müssen. Man muss einfach wissen, was man benötigt und dafür die beste Lösung finden.

Falsch ist keine der beiden Variante, da keine redundante Datenhaltung stattfindet.

mfg
Josef

 

Hier eine angepasste Version von Maike
Kategorie_Test02.rar
Leider krieg ich die Löschknöpfchen im Ufo nicht zum laufen ... da kommen ständig Fehlermeldungen ... hab schon herumexperimentiert - bin mir sicher, dass ein paar Angaben im allgem. Modul fehlen.

- Ebenfalls wäre es wünschenswert das eine neue Kategorie nicht einfach so im Hfo erscheint, sondern erst nach einer MsgBox "Wollen Sie dieser Person eine neue Kategorie zuweisen?"
- Es ist auch total unrealistisch, dass eine Person mehr als 3 Kategorien angehört! D.h. max. 3 möglich - danach message.

Wäre es möglich alle "functions" (das Ufo betreffend) in nur einem Modul zusammenzufassen ?

Bitte helft mir, ich als Greenhorn krieg das - in nützlicher Frist - nie und nimmer hin - auch nicht mit meinen tollen Büchern.
Danke

 

\@Josef

Wäre es möglich wenn Du anhand der obigen (upgeloadeten) DB die Option mit den Kat_Nr (d.h. Zahl anstelle AutoWert) noch anschauen könntest ?
Siehst Du also eine Möglichkeit ?

Ebenfalls wäre es interessant zu wissen, ob diese "selbstdefinierten" Zahlen, wenn sie in Zukunft irgendwann einen AutoWert "kreuzen" (d.h. Zahl & AutoWert gleich) zu Problemen kommen könnte ?

 

Hallo!

Wie soll sich der Inhalt des PK mit einem anderen Feldwert "kreuzen".
Welcher Wert dort steht ist doch egal.

Zum Verständnis:
In der Tabelle tbl_KatGruppePersonen werden Datensätze aus den Tabellen tbl_Personen und tbl_KategorieAuswahl miteinander verbunden. Das erfolgt durch das Abspeichern der PK aus diesen beiden Tabellen in einem Datensatz.
Der Tabelle tbl_KatGruppePersonen ist es dabei vollkommen egal, ob der PK-Wert aus einem Autowert-Feld oder aus einem "normalen" Long-Int-Zahlenfeld kommt. (Anm.: Das Autowert-Feld ist in deiner Tabelle ebenso ein Long-Int-Zahlenfeld.)

BTW:
Warum ist "Auswahl" im Namen von "tbl_KategorieAuswahl"?
Das sind doch im Prinzip nur die Kategorien, die es gibt. Wo ist da die Auswahl?
Die Auswahl kommt doch erst über das Dowpdown usw.
Wenn ich "Auswahl" in einem Datenquellen-Namen lese, würde ich erwarten, dass das nur eine vorgefilterte Teilmenge der vorhanden Daten ist.

mfg
Josef

 

Wie schon in #8 beschrieben:
Code:

Da weigere ich mich. Weil ich solche blöden Fragen hasse. Wenn ich auf einen Button klicke oder ein Kombifeld betätige, dann bestimmt nicht, weil ich nicht löschen oder hinzufügen will und ja ich bin mir sicher *mad.gif*
Das gleiche gilt für die 3 Kategorien.

Die Frage versteh ich nicht wirklich. Was sollte dich daran hindern? In einigen Fällen ist es sogar zwingend, die Ereignisse im Formularmodul zu definieren.

maike

 

Also, erstmal vielen Dank jetzt klappte es mit dem Löschen - Es scheint so, als ob sich die Gemüter (allgemein) erregen wenn von meinen Wünschen die Rede ist... man darf ruhig davon ausgehen, dass ALLES worum ich bitte seine Begründung hat - auch wenn dies auf den ersten Blick nicht sichtbar ist. *wink.gif*
1. als ehem. PC-Supporter weiss ich, welche Dummheiten sich gewisse, weniger erfahrene, User leisten. Bitte gehe nicht immer von mir aus...
2. ist das Hinzufügen (und Löschen) einer Kategorie keine Beiläufigkeit - es soll ein psychologische bzw. optische Marke gesetzt werden.
3. Wie ich schon mehrfach erwähnt habe bin ich Anfänger und mit Euren Gedankenmodellen nicht vertraut.

Sorry wenn Du mich nicht verstehen kannst.
Danke für die Nachsicht

 

Sorry, Ja natürlich, hier habe ich einen Gedankenfehler gemacht! *redface

 

Ja, du hast sicherlich recht, werde dieses Detail korrigieren.
Danke für den Hinweis!

 

wunderschönen guten Tag allerseits,

ausgehend von der upgeloadeten DB habe ich noch ein paar kleine Bitten.
Kategorie_Test03.rar
1.
Wenn ich z.B. eine Kategorie z.B. - irrtümlicherweise -
2x auswähle ... kommt Fehlermeldung:
Laufzeitfehler 3022 (weil mehrfach vorkommende Werte nicht möglich sind)
Hier wäre es wünschenswert diese zu unterdrücken und anstelle dieses Laufzeitfehlers eine geordnete Message wie z.B. "Person kann nicht in zwei Kategorien gleichzeitig sein" oder gar keine Reaktion (is auch recht).

2.
Wenn ich versuche ein leeres Feld zu löschen - weil auch bei leeren Feldern im Ufo (wegen Endlosansicht) dieser Löschknopf daneben steht - kommt die Fehlermeldung:
Laufzeitfehler 3075, Syntaxfehler (fehlender Operator) in Abfrageausdruck 'KGPID='
Auch hier wäre entweder eine geordnetere Message angebracht oder gar keine Reaktion (d.h. unterdrückung des Laufzeitfehlers) oder ein Ausblenden des Löschknopfes bzw. des leeren Felds generell, solange keine Auswahl erfolgt ist.

Falls es möglich wäre diese Unstimmigkeiten irgendwie zu korrigieren bzw. zu unterdrücken ... wäre ich sehr froh.
Der User soll sich, logischerweise, ja nicht unnötig mit dem "Debug-Modus" herumschlagen müssen *holy
Merci

 

Ok, habe das mit der Unterdrückung (inkl. MsgBox) dieser beiden Laufzeitfehler schon selbst lösen können! *cool.gif*
Trotzdem sehe ich dieses Vorgehen nicht in jedem Fall als intelligenteste Lösung!