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

Nachfrage:
Code:

Das mit dem Zählen der Kategorien würde ich in eine kleine Hilfsfunktion auslagern, die dann als Variable die PersonenID erhält und als Ergebnis die Anzahl der Kategorien ausspuckt. Je nachdem welche Zahl von der Funktion ermittelt wird kannst du dann den obigen Code noch an deine Bedürfnisse anpassen (musst du eh).

 

Hilfsfunktion die vor der Zuweisung prüft, ob nicht bereits zugewiesen. Oder quick&dirty mit "DoCmd.SetWarnings = False"

Vor der Codeausführung mit IsNull prüfen ob alle nötigen Werte im Formular ausgefüllt wurden. Siehe meinen Code aus dem vorigen Beitrag.

Nur am Rande: Wenn du im VBA-Editor ein Kennwort für den Code einstellst, dann bleibt die "Debuggen"-Schaltfläche in den Fehlermeldungen grau, d.h. inaktiv.

 

Guten Tag Dave
Vielen Dank nochmals für Die freundliche Hilfestellung.
Das mit dem VBA-Editor finde ich interessant - wusste nicht, dass so was existiert *Smilie
Mein Problem liegt offenbar bei:
DoCmd.RunSQL "INSERT INTO ..."

................

edit ... hab wohl etwas voreilig gehandelt ... hab's selbst rausgefunden ... jetzt funktionierts offenbar ...
bis auf ein Neues ... *tongue.gif*

 

Hilfe! *entsetzt
Habe gerade festgestellt dass alle Kategorie-Auswahlen (u. Kombinationen) im Ufo abgespeichert werden, somit blähen sie die DB extrem auf. Vielleicht liegt das "Aufblähen" auch an etwas anderem was ich grad nicht durchblicke ...
Wenn ich die Kat. aus dem Ufo entferne, werden die Werte auch aus der Tabelle entfernt! Das ist nicht sinnvoll!
Im Ufo dürfen doch keine Daten gespeichert werden! Dies würde die DB in kürzester Zeit extrem unnötig aufblähen - oder nicht?
Kann man erreichen, dass die Daten (Text-Bezeichnungen) der Kat. im Hfo zwar (wie bisher) angezeigt, aber im Ufo nicht endlos mitgespeichert werden ? Ich weiss, das mag zwar eigenartig klingen, ist aber eine ernsthafte Performance-Schwäche - spätestens nach 2000 Datensätzen! Es läuft jetzt schon langsam mit gerade mal 10 Datensätzen!

Weiss Jemand von Euch Rat ?
Wenns nicht anders geht, können diese Text-Beschreibungen der Kat. auch in einer zusätzlichen (neuen) Tabelle abgespeichert werden ...
betr. Zugriffszeitoptimierung wäre ich auch nicht unglücklich ...
Hier nochmals der Code:
...
Dim iMsg As Integer
If IsNull(Me!KatFKAuswahl) Then
MsgBox "Achtung! Kategorie auswählen!", vbOKOnly, "FEHLER"
Else
iMsg = MsgBox("Wollen Sie dieser Person eine neue Kategorie zuweisen?", vbOKCancel, "Hinweis")
If iMsg = vbOK Then
DoCmd.SetWarnings False
DoCmd.RunSQL "INSERT INTO tbl_KatGruppePersonen (PersFK, KatFK) " & "VALUES (" & Me.IDPers & ", " & Me.KatFKAuswahl & ")"
DoCmd.SetWarnings True
Me.Requery
... etc.

Bin wieder mal deprimiert! *frown.gif*

 

Hallo nochmals
Ebenfalls wäre es von Nutzen, wenn die Anweisung & Me.IDPers ... welche aus einem Auto-Wert gebildet wird durch & Me.PersID ... welche aus einem selbstdefinierten (eindeutigen) alphanumerischen-Wert besteht, ersetzt werden kann. wenn ich das versuche muss ich irgendwelche Parameterwerte eingeben ... und es passiert nichts! Die PersID ist eigentlich mein Personal-ID Textfeld... mit der Gefahr, dass wir diese Diskussion bereits schon abgehackt haben... *redface

DoCmd.RunSQL "INSERT INTO tbl_KatGruppePersonen (PersFK, KatFK) " & "VALUES (" & Me.IDPers & ", " & Me.KatFKAuswahl & ")"

Wäre um ein paar hilfreiche Worte sehr froh!

 

Hallo!

Die Daten werden in der Tabelle tbl_KatGruppePersonen gespeichert, an das das Unterformular gebunden ist.
Wie willst du die Daten aufheben, wenn du sie nicht in einer Tabelle speicherst?

Im von dir zuletzt hochgeladenen Beispiel ist ein Code im Hauptformular, der darfür sort, dass die im HF ausgewählte Kategorie im UF gespeichert wird.

Code:

ein Code zum Löschen ist etwas eiganartig:

Im UF steht:
Code:

In einem allgemeinen Modul steht:
Code:

Was erwartest du vom Code, wenn du den so schreibst? Wie soll der Ablauf sein?
Vor allem: wie soll die allgemeine Prozedur erkennen, welche KGPID gelöscht werden soll?


Tipp:
Verwende im Kopf eines Codemoduls immer "Option Explicit" (damit das bei neuen Codemodulen automatisch gesetzt wird, kannst du das in den VBA-Optionen einstellen. Option: "Require Variable Deklaration")

mfg
Josef

 

Hallo Josef -
Ja, es ist schon logisch dass das so ist, aber wie kann man das rasche Aufblähen der DB verhindern ??
Dies ist nur eine Test-DB (beinahe ohne Grafik) Grösse: 3200 KB
Meine Haupt-DB (mit Grafiken u. Farbgestaltung) hat nur eine Grösse von ca. 1988 KB... Das ist was mich aufgeschreckt hat!
Was kann ich tun oder überprüfen ?

Danke für Deine Code-Beispiele, werde ich gleich prüfen ...

 

Hast du mit Frontend-/Backend-Trennung getestet?

Falls du nur eine Datei für Frontend und Backend zum Testen verwendest, kommt das Aufblähen sehr wahrscheinlich von den Änderungen der Formulare und der Codemodule.

Das Speichern von Datensätzen vergrößert zwar auch das Backend - ist ja auch logisch, irgendwo müssen die zusätzlichen Daten vorhanden sind - aber das sollte sich in Grenzen halten.
Falls du Datensätze löscht, wird die DB nicht kleiner. Das Backend wird erst beim Komprimieren verkleinert.

Das Entwicklungs-Frontend solltest du regelmäßig komprimieren.
Ich führe auch regelmäßig ein Decompile durch. Ein regelmäßiges Backup ist selbstverständlich - bzw. noch besser: ein Quellcodeverwaltungssystem verwenden.


Beim Backend kann ich dir keine aktuellen Erfahrungen zum Komprimieren nennen, da ich schon lange kein Access-Backend mehr einsetze.

mfg
Josef

 

Hallo Josef ... vielen Dank für die Tipps
Betr. Aufblähen:
... muss gestehen - hab das "Dekomprimieren" vergessen, jetzt ist alles wieder normal! *Aufatmen* *rolleyes.gif*
Es scheint so, als ob die gespeicherten Informationen im Ufo bisher doch nicht so ins KB-Gewicht fallen würden, wie bisher angenommen ... was ja auch nicht logisch wäre...

Betr. der Verwirrung betr. dem Lösch-Befehl (siehe oben) verstehe ich jetzt was du meinst...
Du bist von einer "älteren" DB Version (unter #22) ausgegangen anstelle der "aktuelleren" #29... Modul ist nicht mehr vorhanden ...

Ich arbeite zurzeit noch nicht mit FE - BE ... das kommt erst.
Darf ich fragen was dich bewogen hat nicht mehr mit BE zu arbeiten ?

 

[OT]

Ich verwende statt einem Access-Backend meist ein MSSQL-Server-Backend, da das z. B. auch gesichert werden kann, während es benutzt wird.
Außerdem sind komplexere SQL-Anweisungen effizienter umsetzbar, da man diese serverseitig ausführen lassen kann.

 

Interessant...
Arbeitest Du mit der kostenlosen Express-Version von MS-SQL oder mit der kostenpflichtigen ? und ist bei der kostenlosen Version alles wesentliche dabei ?
Meine Absicht ist, die DB in FE u. BE aufzuteilen und auf dem Server via ODBC-Schnittstelle zur Verfügung zu stellen...

 

Ich verwende beide - sind für meine Bedürfnisse aber 1:1 austauschbar.
Bei der Express-Version sind es ein paar Features nicht dabei. Man kann damit z. B. keine Wartungspläne einstellen. Die Backups muss man über den Windows-Task-Planer steuern. Das funktioniert aber ohne Probleme.

Bezüglich Wechsel von Access-Backend zu SQL-Server-Backend sind schon ein paar Punkte zu beachten.
Da findest du aber bestimmt einiges, wenn du Google & Co. fragst.

Wenn man bereits beim Access-Backend datenbankortientiert entwickelt hat, wird da nicht das große Problem sein.

Falls du derzeit noch am Anfang der Anwendungsentwicklung bist, würde ich an deiner Stelle gleich auf MSSQL umsteigen, falls du später kein Access-Backend einsetzen willst.
Dann kannst du von Anfang an schon die Stärken eines aktiven DBMS ausnutzen und Datenarbeit vom Server durchführen lassen.
Mit gespeicherten Prozeduren im SQL-Server hast du ein Werkzeug, von dem ein Entwickler mit einem Access-Backend nur träumen kann. ;-)

Wichtig: Access-Abfragen nur für Layout-Optimierungen einsetzen. Joins usw. gehören in Sichten, die dann per ODBC in das Frontend verknüpft werden. Dann nutzt du die Fähigkeiten des DBMS aus. Falls du in Access-Abfragen die ODBC-Tabellen verknüpfst, wird der Ausführungsplan möglicherwiese sehr Jet-lastig und es entsteht eine nicht optimale Abfrageausführung.
SQL-konforme Filter auf Sichten werden an das DBMS per ODBC weitergleitet und dann nur noch das Ergebnis zurückgeschickt.

Es gibt bestimmt noch einiges, wie man das Zusammenspiele eines SQL-Server-Backends mit einem Access-Frontend verbessern kann.
Darüber gibt es aber bestimmt genug im Netz zu finden, daher erspare ich mir weitere Ausführungen. *wink.gif*

mfg
Josef

 

Vielen herzlichen Dank Josef! Deine wertvollen Anmerkungen werde ich mir zu Gemüte führen! *Smilie

Hier habe ich noch eine aktuellere Version upgeloaded ...
Kat_Test04_.rar
Ist es Dir möglich noch folgende Schwierigkeiten anzuschauen?:

1. Die Geschwindigkeit der Darstellung der paar wenigen Datensätzen scheint mir ziemlich langsam - mit was hat das zu tun?

2. Jedesmal wenn ich eine Kategorie auswähle oder eine zusätzliche erstelle, dann hüpft der Datensatz auf den ersten DS zurück anstatt beim aktuellen DS zu bleiben.

3. Ich habe zur Übersicht das - zuvor ausgeblendete - Textfeld IDPers sichtbar gemacht. In der Abfrage wird hier der AutoWert (IDPers) aus der tbl_Personen bezogen und zusammen mit der KatFKAuswahl - welches eine Zahl ist aber ebenfalls ein AutoWert aus tbl_Kategorie - kombiniert, und gemeinsam in die Tabelle tbl_KatGruppePersonen gespeichert.

Code:

Ist es nicht möglich diese IDPers (AutoWert) mit der PersID (selbstdefinierte eindeutige Ziffer > alphanumerisch) entweder zu ersetzen oder diese (PersID) wenigstens in einer separaten Spalte in der Tab. tbl_KatGruppePersonen ebenfalls miteinfügen zu lassen? (siehe Hfo)

Es ist eben so, dass ich ein tolle Function (Modul) habe, welches eine alphanumerische Personal-ID generiert. Diese Funktion (Personal-ID) wäre ansonsten nur auf Formularen sichtbar und nicht in der wichtigen Tabelle tbl_KatGruppePersonen - aber genau das möchte ich ändern! Es SOLL auch in dieser Tabelle sichtbar sein!
gewisse Redundanzen (inkl. Kopfschütteln) nehme ich in Kauf! *wink.gif*
Wenn die eine oder andere Lösung ginge, wäre ich schon sehr dankbar

Wenn keine unerwarteten Probleme mehr auftreten, würde ich dieses Thema gerne schliessen.

 

Hallo,

genau das wäre aber falsch und überflüssig. Du kannst ohne weiteres diese Personal_ID über eine Abfrage jederzeit anzeigen. Es ist ja der Sinn von Schlüsselfeldern genaus solche Redundanzen zu vermeiden. Der Tabelleninhalt der Tabelle tbl_KatGruppePersonen ist völlig nebensächlich, da eine Tabelle für den User nicht sichtbar sein sollte. Und wenn Du eine Abfrage erstellet mit der Tabelle tbl_KatGruppePersonen und der Tabelle tbl_Personen mit Verknüpfung über die IDPers hast Du auch die PersID zur Anzeige zur Verfügung. Es würde der Datenbanklehre widersprechen diese Feld auch zu speichern.

 

Wo siehst du die "Langsamkeit"?
Beim Öffnen des Formular passiert eigentlich nicht viel. - Es werden 2 Kombinationsfelder und 2 Formulardatenquellen geladen wovon die im Unterformular mit der des HF verknüpft und somit gefiltert werden.
Man kann da optisch schon noch ein wenig beschleunigen, es wird aber vermutlich keinen wirklich erkennbaren Unterschied bringen.
Was man machen könnte: das Unterformular und die Datenquellen der Kombinationsfelder erst laden nach dem das Formulars sichtbar wurde. Da dauert dann zwar gemessen um ein paar Nano- bis Millisekunden länger, für den Anwender sieht es aber schneller aus.

Das wird durch die Requery-Anweisung ausgelöst.
Du könntest nach Requery den Fokus auf den gewünschten Datensatz legen. (Beispielcode findest du irgendwo in www.donkarl.com)

Ich geh nur auf die mögliche Umsetzbarkeit ein und nicht auf die Sinnhaftigkeit. *wink.gif*

Du kannst im Prinzip IDPers ganz aus der Tabelle nehmen und den PK auf PersID stellen. Dann musst du die Tabelle tbl_KatGruppePersonen entsprechend anpassen und PersFK anpassen, damit dort die Text-Schlüssel gespeichert werden können.
Ebenso ist die Insert-Anweisung auf SQL-konforme Textspeicherung anzupassen.

Das ist nicht sinnvoll. Das wäre ein eindeutig nicht notwendiger Normalisierungsverstoß.

Hast du das AEK-Skript von Michael Zimmermann schon gelesen und zumindest teilweise verstanden? Falls nicht, nimm dir Zeit dafür, bevor du an einer Anwendung weiter bastelst. Du verschwendest möglicherweise sonst nur deine Zeit.

mfg
Josef