Access-o-Mania

Hallo Accessfreunde,

befasse mich seit sehr kurzer Zeit mit Codes und habe nun ein Problem.

Habe folgende Hauptformulare:
- Artikelnummernkreise
- Artikelstamm

Dazu ein Unterformular:
- Artikelkategorien

Habe in die beiden Hauptformulare unter "Bei nicht in Liste" den "4.13 Kombi-Eintrag Variante 2" von Donkarl eingegeben - funktioniert perfekt.
Dann habe ich in das Unterformular den Zusatzcode unter "Beim Schließen" eingegeben, der das Unterformular schliesst und den Wert in das Hauptformular überträgt.
Zuerst mit Bezug auf eins der beiden Hauptformulare - hat perfekt funktioniert.
Erst als ich mit Bezug auf das zweite Hauptformular den gleichen Code eingegeben habe (durch einen waagrechten Strich getrennt), erscheint immer die Meldung "Laufzeitfehler 40036".

Ich vermute, das muss an den beiden gleichen Spaltenbezeichnungen in den beiden Hauptformularen liegen (Artikelkategorie).
Ich würde diese Bezeichnungen gerne beibehalten - was kann man da tun?

Habe mal zwei stark vereinfachte Dateien vorbereitet:
- Datei ohne Fehlermeldung (-> da fehlt leider der Codezusatz mit Bezug auf eines der beiden Hauptformulare)
- Datei mit Fehlermeldung (-> Codezusatz ist ordnungsgemäß drin, funktioniert aber nicht)

Für eine Hilfe wäre ich sehr dankbar.

Viele Grüße

Rainer

[Anhang gelöscht durch Administrator]

Hallo,
mit Access2007 hast Du noch nicht so viel Glück. Konvertiere mal nach Access2003, Access2007 haben noch nicht so viele.

Hallo MzKlMu,

wie kann ich in eine ältere Version speichern?
Wenn ich "Datenbank speichern als" gehe, bekomme ich unter "Dateityp" nur "Microsoft Access-Datenbank" angeboten - keine Jahresversionen.

Viele Grüße

Rainer

Hallo MzKlMu,

habs jetzt begriffen - unter "Speichern und Veröffentlichen" natürlich.

Also - hier die 2003-er Dateien.

Vielen Dank und Gruß

Rainer

[Anhang gelöscht durch Administrator]

Hallo,
ich habe Zweifel, dass das Datenmodell stimmt.
Kannst Du mal die Tabellenzusammenhänge erklären?

Beziehungen lässt man nicht über Textfelder laufen. Du solltest also auch für die Kategorien einen Zahlenprimärschlüssel einbauen.

Hallo MzKlMu,

hatte früher in jeder Tabelle eine ID-Spalte, habe in einem früheren Beitrag ("Datum oder Zahl" auf Seite 2) von Franz (DF6GL) eine stark vereinfachte Variante von Tabellen als Vorschlag erhalten, die auf ID-Spalten verzichten (da, wo man sie nicht braucht) - finde ich nicht schlecht und funktioniert eigentlich einwandfrei (kann man auch downloaden).

Erklärung: Ich möchte, je nach Bedarf, entweder im Formular "Artikelnummernkreise" oder im Formular "Artikelstamm" (je nachdem, worin ich arbeite) eine neue Artikelkategorie im Unterformular "Artikelkategorien" anlegen können. Fantasiewerte "Klein", "Mittel" und "Groß" sind schon drin.

Bitte schau Dir auch die Unterschiede des Codes "Form_Artikelkategorien" der beiden Dateien an.

Viele Grüße

Rainer

Hallo,
OK, lassen wir das mit der ID mal beiseite.
Ich wollte mal die Tabellenzusammenhänge wissen, nicht was Du im Formular machen willst.
Ich glaube nämlich nicht, dass die Beziehungen so passen. Und davon hängt ja auch das Formular ab.

Hallo,

ZitatIch glaube nämlich nicht, dass die Beziehungen so passen ...

Und genau so ist es ...  sie stimmen nicht (ganz)
Beziehungen sind zwar über den Primärschlüssel hergestellt aber es wurde kein ID Feld verwendet.

Das Nachschlagefeld in der Tabelle Artikelstamm habe ich rausgeschmissen - Nachschlagefelder bitte IMMER vermeiden!
Die Formulare Artikelnummernkreise und Artikelstamm habe ich geändert. Die Datenherkunft der Kombifelder an die Tabellenstruktur angepasst.
Das Formular Artikelkategorien ist jetzt so konzipiedrt, dass Kategorien erfasst und geändert werden können.
Zu Demonstrationszwecken habe ich das Formular zu einem Ungebundenem gemacht und ein paar Zeilen VBA eingebaut.

Zitat... erscheint immer die Meldung "Laufzeitfehler 40036".

Der Fehler entstand dadurch, dass du in einem Formular 2 x das Ereignis 'Beim Schließen' eingegeben hattest - das geht so nicht ganz ...   ;)

schau dir mal das geänderte Beispiel im Anhang an, vielleicht kannst du was damit anfangen.   ;D

p.s. allerdings habe ich das Ding als *.accdb eingestellt.


[Anhang gelöscht durch Administrator]

Hallo Peter,

erstmal Danke! Ui - das ist komplex.  :o
Hier ist mir einiges unklar, wie z.B.:
1. Warum sollte man Nachschlagefelder vermeiden?
2. Woher kommen die Daten dann? In den Haupttabellen ist ja jetzt nix mehr unter "Nachschlagen" eingetragen.

Was mich jetzt ein wenig verdutzt: Ist der Vorschlag von Franz aus einem früheren Beitrag, in dem es über etwas anderes ging ("Datum oder Zahl", Seite 2, Antwort #23), nicht ganz korrekt? In der von ihm korrigierten Datei sind 2 von 3 Tabellen ohne ID-Spalte. Habe meine ganzen Untertabellen (10 Stück) nach diesem "ID-losen Schema" aufgebaut. Welche Probleme können da entstehen?

Gute Nacht und schöne Grüße

Rainer

Hallo, guten Morgen,

Zitat1. Warum sollte man Nachschlagefelder vermeiden?

Nachschlagefelder vernebeln den Blick auf das Datenmodell und gaukeln Beziehungen
vor, die in einem normalisierten Datenmodell NICHT existieren. Nachschlagefelder in Tabellen werden auch
deshalb nicht benötigt, da in Tabellen keine Daten eingegeben werden sollen sondern die Datenmanipulation
ausschließlich über Formulare zu organisieren ist.

Zitat2. Woher kommen die Daten dann? In den Haupttabellen ist ja jetzt nix mehr unter "Nachschlagen" eingetragen.

In den Formularen befinden sich Kombifelder, die im weitesten Sinn diese Nachschlagefelder darstellen.
Die Daten für die Kombifelder stammen aus den 'Nachschlagetabellen'
Sie liefern bei Auswahl den Primärschlüssel des angezeigten Eintrages, der dann wiederum als Fremdschlüssel in die Datenherkunft des Formulars eingetragen wird.
Du siehst im Datenbankdiagramm die Beziehungen in der Form, wie sie dabei Anwendung finden. Wenn du die Tabellenentwürfe anschaust,
wirst du erkennen, dass die Fremdschlüssel (von mir mit FK gekennzeichnet) als Zahlenfelder ausgeführt sind.
Somit wird auch klar(er) wie eine Beziehung richtig zu erstellen ist - nur über die Schlüsselfelder und diese möglichst als Zahlenfelder deklariert.

Zum Thema ID in Tabellen sei von meiner Seite folgendes zu sagen:
Es ist nicht unbedingt notwendig ALLE Tabellen mit ID-Feldern auszustatten.
Tabellen, welche als s.g. Zwischentabellen fungieren, (diese werden erstellt, wenn n:m Beziehungen aufgelöst werden)
benötigen nicht unbedingt ein eigenes ID-Feld, können aber eines erhalten.

ZitatHabe meine ganzen Untertabellen ...

Welche Art von Tabellen bezeichnest du als Untertabellen - meinst du die Tabellen, die auf der n-Seite einer 1:n Beziehung stehen?
Wenn du diese meinst, ist es nicht unbedingt nötig diese mit einem Primärschlüssel zu versehen. Da passiert auch nichts deswegen.  ;)

HTH

Halo,
zu den Nachschlagefeldern:
Access Anfänger: Die Nachteile von Nachschlagefeldern
aus DBWiki, dem Datenbank-Entwickler-Wiki

Man sollte Nachschlagefelder in Tabellen vermeiden, denn

  1. Ein Nachschlagefeld verbirgt den eigentlichen Feldinhalt. Wenn man beispielsweise eine Tabelle in Datenblattansicht öffnet, wird ein Firmenname dargestellt, obwohl in Wirklichkeit im Feld die Kundennummer steht, und der Firmenname aus einer anderen Tabelle stammt. Nachschlagefelder verhindern, dass Datenbanken sauber durchstrukturiert angelegt werden.

  2. Eine Abfrage, die das Nachschlagefeld verwendet und nach dem dargestellten Wert sortieren soll, funktioniert nicht. So wird im obigen Beispiel nicht nach dem Firmennamen, sondern nach der Kundennummer sortiert. Ebensowenig funktioniert die Angabe des Werts als Kriterium - auch hier müsste man die Nummer anstelle des Namens verwenden, um Ergebnisse zu erhalten. Wenn man den Wert aus einer Wertliste eines Kombinationsfelds auswählt, kann es passieren, dass gültige Daten mit falschen Werten überschrieben werden.

  3. Das Nachschlagefeld beinhaltet eine (intern angelegte) Beziehung zwischen den Tabellen sowie die Anlage zusätzlicher Indizes, die in aller Regel überflüssig sind und die Datenbank unnütz aufblähen. Auch kann es vorkommen, dass man auf diese Weise die maximal zugelassene Anzahl von Indizes je Tabelle unwillentlich überschreitet.

  4. Ein Kombinationsfeld auf der Basis eines Nachschlagefelds kann bei Filterung des Formulars dazu führen, dass der Filter mit dem Formular gespeichert wird. Beim nächsten Öffnen des Formulars fehlt der Wert und wird nachgefragt, was wiederum zu einem Fehler führt.

  5. Berichte, deren Datenherkunft Nachschlagefelder enthält, benötigen Kombinationsfelder zu deren Darstellung, die den Bericht langsam und ineffizient machen können.

  6. Die Datenbank kann nicht vernünftig von außen abgefragt (beispielsweise in Form einer Datenquelle eines Word-Serienbriefs) oder exportiert werden, da die Nachschlagefelder nicht nach außen gereicht werden.

  7. Wenn man das Access-Sicherheitssystem verwendet, reichen die Berechtigungen oft nicht aus, um die Nachschlagefelder mit Inhalt zu füllen, was zu schwer nachzuvollziehbaren Fehlern führt. Das gilt insbesondere, wenn man aus Sicherheitsgründen mit Abfragen mit "WITH OWNERACCESS OPTION" arbeitet.[/quote]

DBWIKI ist nicht mehr Online, daher als Zitat.

Zu den Schlüsselfeldern.
Wenn ein Feld wie z.B. das Jahr ohnehin eine Integerzahl ist, braucht man keine extra ID.
Franz hat ja auch in dem zitierten Beitrag durchaus auch Zweifel gehabt auf IDs zu verzichten. Ich würde keine Doublezahlen als PS verwenden und schon gar keine Texte. Texte erfordern immer eine besondere Behandlung beim Suchen, Referenzieren etc.
Auch bei n:m Tabellen würde ich immer eine PS Feld einbauen, einfache weil es später einfacher wird.

Hallo Peter, hallo MzKlMu,

vielen Dank für Eure Antwort und Hilfe!!!

@ Peter:

ZitatWelche Art von Tabellen bezeichnest du als Untertabellen - meinst du die Tabellen, die auf der n-Seite einer 1:n Beziehung stehen?

Ich bezeichne die Tabellen als Untertabellen, in die die "Grundwerte" eingetragen werden, in meinem Fall z.B. die Untertabelle "Artikelkategorien" (1-Beziehung). In der Haupttabelle "Artikelstamm" (n-Beziehung) wähle ich dann diese Werte aus.

Um meinen Tabellen eine einheitliche Struktur zu geben, werde ich diese umstrukturieren und zunächst folgendes tun:
- überall ein ID-Feld einbauen und die Tabellen über die ID kommunizieren lassen.
- Nachschlagefelder zwischen Tabellen entfernen und diese in die Formulare einbauen.

Werde mich wieder melden - schönes Wochenende!

Viele Grüße

Rainer

OK,

Das mit den Untertabellen ist gut so - nur solltest du diese Tabellen künftig als Nachschlagetabellen bezeichnen, das sind sie in deinem Fall offensichtlich  ;)

Ich würde den Begriff Untertabellen eher mit einer Detailtabelle gleichsetzen.

ZitatUm meinen Tabellen eine einheitliche Struktur zu geben...

Davon würde ich dir dringendst abraten!
Tabellen werden nicht so erstellt, dass sie einheitlich aussehen, das kannst du bei der Benennung und bei den Feldnamen machen, hier macht es auch Sinn eine gewisse einheitliche Linie zu ziehen.

Tabellen werden entsprechend ihrer Aufgaben, ihres Inhaltes und ihrer Funktion erstellt, designed und eingesetzt.
Du benötigst in JEDER Tabelle, die sich auf der 1- Seite einer Bezihung befindet ein ID-Feld, das solltest du aber auch nicht einfach ID nennen sondern einen Bezug zur Tabelle herstellen z.B. 'KundenID'
Diese Felder werden in der Regel als Autowert-Felder geführt und bekommen die Funktion des Primärschlüssels umgehängt.
Auf der n - Seite der Bezeihung brauchst du keinen Priimärschlüssel, also auch kein ID Feld in der Tabelle!

Hier deklarierst du die Fremdschlüssel z.B. Kunden_FK (FK steht für Foreign Key, Fremdschlüssel) und führst diese Felder als Zahl, Long Integer aus.
Und NUR über diese beiden Felder werden die beiden Tabellen in Beziehung gesetzt und zwar so, dass referenzielle Integrität eingestellt ist.

Schau dir bitte UNBEDINGT die Links #1 und #2 in der Signatur von DF6GL an!!!!  

HTH

Hallo Peter,
Du schreibst auf der n-Seite brauchst Du keinen Primärkey.
Ich habe gelernt das   k e i n e   Tabelle ohne Primärkey sein sollte und wenn es nur eine ID mit Autowert ist.
Ansonsten gibt es doch immer einen eindeutigen Schlüssel (man weis ja nie wo man die Tabelle vieleicht in zwei Jahr
noch gebraucht).

Gruß

Johann

Hallo,

ZitatIch habe gelernt das   k e i n e   Tabelle ohne Primärkey sein sollte und wenn es nur eine ID mit Autowert ist

Es gehen die Meinungen zu diesen Themen immer wieder recht weit auseinander.
Die grundlegendste Funktion eines Primärschlüssels ist es, einen Datensatz mit einem EINDEUTIGEN Kennzeichen zu versehen.
Diese Notwendigkeit besteht mit Sicherheit dann, wenn sich die Tabelle entweder als StandAllone darstellt oder die 1 Seite einer 1:n Beziehung bildet.
Aussagen, die darauf hinweisen, dass Tabllen ohne PK in Beziehungen nicht verwendbar sind stimmen definitiv nicht, solange es sich bei der betroffenen Tabelle
um die n-Seite handelt.

Zitatund wenn es nur eine ID mit Autowert ist

IMHO die einzig wirklich brauchbare Art einen Primärschlüssel zu definieren, da bei Autowertfeldern die Fehlerwahrscheinlichkeit praktisch gleich NULL ist.

Es ist m.E. Ansichtssache, eine Detailtabelle, die über PK/FK mit der Mastetabelle in Beziehung gesetzt ist, mit einem PK zu versehen.
Wenn es aus dem Grund erfolgen sollte um einen eindeutigen Index in der Tabelle zu haben halte ich entgegen, dass ich den bei einer Detailsuche eigentlich niemals einsetzen werde.
Die Detailsuche wird immer über den FK stattfinden, wobei da Sinn macht diesen zu indizieren, bzw. die Indizierung nicht zu entfernen.
Wenn u.A. die Suchen oft gemacht werden, die Anzahl der Datensätze in der Tabelle hoch ist und die Suche effizient und vorallem schnell erfolgen soll, kann das enorme Vorteile bringen
Es wird höchst selten vorkommen, dass der PK einer Detailtabelle mit einem Abfragekriterium belegt wird (WHERE DetailDSID= irgendeinWert)

So wird es bei der Suche nach Artikeln in einem Warenkorb wohl kaum interessant sein welche ID die Datensätze mit den Artikeln
im Warenkorb haben, da wird mich eher interessieren welche ID der Warenkorb hat um dann die zugeordneten Artikel/Inhalts-Datensätze (INNER JOIN über WarenkorbID )zu finden.

Es ist jedoch trotz dieser Gegenargumente auch nicht falsch einen Primärschlüssel in reinen Detailtabellen zu haben - es ist halt meist nicht unbedingt notwendig.
Ich habe darauf aber auch schon im Posting oben hingewiesen - ausserdem bin ich der Meinung dass es dem Anfänger / Einsteiger nicht gerade hilfreich beim Erlangen von
Verständnis zu Beziehungen ist, wenn ihm von allen Seiten die Schlüssel um die Ohren geklatscht werden.  :D :D ;D

ZitatAnsonsten gibt es doch immer einen eindeutigen Schlüssel

Nein, in einer Detailtabelle wohl kaum.

Das Argument, dass ich vielleicht in 3 Jahren die Tabelle wo anders einsetzen werde ist für mich keines, dass mich dazu verleiten könnte, in einer Detailtabelle ein Autwowertfeld zu definieren..
Wenn ich in ein paar Jahren die Tabelle wo anders einsetze und einen PK benötige, verpasse ich ihr zu diesem Zeitpunkt ein Autowertfeld.
Die Datensätze, die dann eventuell in der Tabelle stehen werden wahrscheinlich nicht verwendbar sein, da der Tabellenaufbau zum
Erstellungszeitpunkt unter völlig anderen Gesichtspunkten erfolgt ist.
Dass die Einhaltung der 3 Normalformen in so einem Fall auch nicht unbedingt gewährleistet ist, versteht sich dann auch von selbst.
Eine leere Tabelle kann ich nach Bedarf umgestalten - daher wie oben angesprochen ...  nein


;)

Hallo,
ohne die Diskussion über PK in jeder Tabelle neu anzustoßen,  ;D möchte ich aber noch zu Bedenken geben, dass die n-Tabelle auch wieder eine 1-Tabelle sein kann.
Z. B.: Kunde (1) (n) Auftrag (1) (n) Auftragsdetails.
Dann macht auch wieder der PS als Autowert in der Auftragstabelle wieder Sinn. Die letzte Tabelle bräuchte keinen Primärschlüssel, oder man macht einen zusammengesetzten PS.

Hallo,

@MzKlMu
Hallo Klaus, da bin ich ganz und gar bei dir.
Dieses wollte ich gerne - wie von dir skizziert - im Fall einer Beziehung zwischen tblAuftrag und tblAuftragsdetails verstanden wissen,
wo ein PK in tblAuftragsdetails nicht unbedingt benötigt wird und für einen Einsteiger auch eher verwirrend wirkt.
Ich habe aber auch vorhin schon auf diese besondere Konstellation einer REINEN Detailtabelle hingewiesen in der es nicht unbedingt erforderlich ist einen PK zu haben. ::)

ZitatEs ist jedoch trotz dieser Gegenargumente auch nicht falsch einen Primärschlüssel in reinen Detailtabellen zu haben - es ist halt meist nicht unbedingt notwendig.

Hallo Peter,

jetzt will ich sehr vorsichtig Schritt für Schritt vorgehen.

Habe angefangen, Nachschlagefelder in Formularen zu erstellen, dabei bin ich auf einen "Abfragegenerator" gestossen. Soll ich DEN als "Nachschlagefeld" benutzen - so wie in der von Dir geänderten Datei?

ZitatSchau dir bitte UNBEDINGT die Links #1 und #2 in der Signatur von DF6GL an!!!! 

In welchem Thread?
Im hiesigen Thread gibt es keine Antwort von DF6GL.
Im Thread "Datum oder Zahl" ist die Antwort #1 von DF6GL, die Antwort #2 jedoch wieder von mir (und nicht von DF6GL).
Welche meinst Du genau?

Viele Grüße

Rainer

Hallo,

ZitatIn welchem Thread?
Im hiesigen Thread gibt es keine Antwort von DF6GL.

Die Links sind in der Signatur von DF6GL und damit in irgendeiner Antwort von Ihm.
Mit den Zahlen #1 und #2 sind die Links gemeint und keine Beitragsnummern.

Hallo MzKlMu,

ah so! Links - nicht Antworten.  ::)
Habs kapiert!
Danke!!!  :)

Viele Grüße

Rainer

Hallo Rainer,

das ursprüngliche Problem (Laufzeitfehler) entstand durch das 2-malige Vorhandensein der Prozedur Form_Close.
Dieses Problem ist - glaube ich - aus der Welt geschafft  ;)

Die aktuelle Fragestellung hat mit dem Ursprungsproblem dieses Threads nix meht zu tun, weshalb ich vorschlagen möchte, dieses Thema zu beenden.
Wir entfernen uns sonst immer weiter von der Thematik des Ursprungs und das würde wiederum die Trefferquote bei Forumsuchen beeinträchtigen.

Diesen Thread daher bitte in DEINEM ERSTEN Beitrag auf 'gelöst' setzen und ein neues Thema  z.B. Erstellung von Kombifeldern aus Nachschlagetabellen beginnen  ;D  DANKE!

Hallo Peter,

tut mir leid - bin stark vom Thema abgewichen.  :-[

Habe mir Deine Änderungen nochmal angesehen. Das Formular für "Artikelnummernkreise" geht jetzt in einem kleinen Fenster (anders als das auf der gleichen Ebene stehende Formular "Artikelstamm") und von dem ursprünglichen Code (also Fenster schliessen) ist nicht mehr viel zu sehen.
Ich (vor allem als Anfänger) würde gerne auf der "einfachen Ebene" bleiben.
Ich würde alle Formulare gerne als "Ganzfensterformular" öffnen (wie gehabt).
Gibt es auch eine einfachere Alternative zum "Form_Close"-Code?

Als Alternative bleibt mir evtl. auch die Möglichkeit auf Codes zu verzichten und die Fenster der Nachschlageformulare mit einer angebrachten Schaltfläche (die mit dem "X") zu schliessen.

Schönen Abend und viele Grüße

Rainer

Hallo Rainer,

Zitattut mir leid - bin stark vom Thema abgewichen

Ist keine fürchterliche Tragik - wollte nur drauf hinweisen, dass ein neues Thema besser geeignet ist als auf gelösten Problemen weiterzuschreiben.

Um die Formulare als 'Ganzfensterformular' zu öffnen braucht es keinen Code, du musst in den Formulareigenschaften auf der Registerkarte 'Andere' bei PopUp NEIN einstellen.

Zu einem Ereignis gibt es keine Alternative - schließen ist schließen und öffnen ist öffnen ...
Du hast versucht einen neuen Eintrag, der ins Kombifeld eingegeben wurde per Schließen-Ereignis in die Tabelle zu verfrachten, das ist in die Hose gegangen.

Ich habe dir in meinem Beispiel gezeigt, wie das Eintragen der Fremdschlüssel gehandhabt wird ohne ein Formularereignis dazu zu bemühen.
Ich habe angenommen, dass du etwas Kenntnisse bzgl. VBA besitzt, denn es gab (gibt) ja immer noch das 'Not In List' - Ereignis hinter dem Kombifeld,
das aber jetzt nach meiner Umstellung auf Schlüsselwerte nicht mehr in der Form funktioniert wie es gestaltet ist - das kannst du also raus nehmen.

Wenn du nun im Formular 'Artikelstamm' eine Kategorie auswählst, wird diese ohne eine einzige Zeile Code in die Tabelle geschrieben.
.....

ZitatIch (vor allem als Anfänger) würde gerne auf der "einfachen Ebene" bleiben

.....  das ist die einfache Ebene   ;)

ZitatAls Alternative bleibt mir evtl. auch die Möglichkeit ....

Was du damit meinst ist mir nicht ganz klar - welche 'Nachschlageformulare' ?

Das Formular 'Artikelkategorien' dient dazu Artikelkategorien zu erstellen oder bestehende zu ändern.
Die so erstellten oder geänderten Kategorien stehen dann im Formular 'Artikelstamm' als Eintrag/Auswahl im Kombifeld 'Artikelkategorien' zur Verfügung.
Das ist keine Nachschlageformular wenn du das meinst - das ist ein ganz normales Formular zur Eingabe und Bearbeitung von Datensätzen (in dem Fall für die Tabelle 'Artikelkategorien')

Zitat...mit einer angebrachten Schaltfläche (die mit dem "X") zu schliessen

I.d.R. werden Formulare nicht über die X-Schaltfläche geschlossen sondern über einen eigenen, am Formular angebrachten Button mit dem Namen 'Schließen'.
Der Code im Ereignis 'Beim Klicken' dieses Buttons lautet dann:

   DoCmd.Close acForm, "NameDeinesFormulars"

die Abarbeitung dieses Befehls löst seinerseits dann das Ereignis 'Beim Schließen' des Formulars aus .... (das du aber für die derzeitige Funktionalität nicht benötigst)

Insgesamt - glaube ich - musst du dich sehr intensiv mit den Grundlagen der Access-Materie befassen, lernen zu erkennen, wann was abläuft und wie man dieses steuern kann.
Planung von Tabellen, setzen von Beziehungen, Normalisierung, Erstellen von Abfragen, Erstellen von Formularen und Berichten runden das Ganze dann ab.
Das hat noch nichts mit VBA-Programmierung zu tun, ich sehe, dass dir einiges an Kenntnis über funktionale Zusammenhänge fehlt.
Das ist keine Schande, da jeder, der sich mit Access beschäftigt irgendwann mal anfangen muss zu lernen - ist mir nicht anderes ergangen.

Das soll aber bitte nicht heißen, dass wir dir hier im Forum nicht helfen wollen oder werden - aber einen ordentlichen Satz an Grundlagenwissen solltest du dir davon unabhängig rasch aneignen um die eigene Frustgrenze so hoch wie möglich anzusetzen.

HTH

Hallo Peter,

zuerst mal tausend Dank für Deine ausführliche Antwort!  :)

ZitatUm die Formulare als 'Ganzfensterformular' zu öffnen braucht es keinen Code, du musst in den Formulareigenschaften auf der Registerkarte 'Andere' bei PopUp NEIN einstellen.

Aha, das hat ja geklappt - wenn man weiß, wo man's macht!  ;)

ZitatIch habe angenommen, dass du etwas Kenntnisse bzgl. VBA besitzt...

Nein, keine - erst am 23. Januar habe ich begonnen, mich damit auseinander zu setzen, siehe auch meinen Thread "Verknüpfung zu anderem Formular". Wollte auch ursprünglich noch gar nix mit Codes zu tun haben, doch dann kam die große Versuchung, siehe auch oben besagten Thread.

ZitatWas du damit meinst ist mir nicht ganz klar - welche 'Nachschlageformulare' ?

Damit habe ich das Formular "Artikelkategorien" gemeint - habe mich etwas missverständlich ausgedrückt.  ::)

ZitatI.d.R. werden Formulare nicht über die X-Schaltfläche geschlossen...

Die habe ich nicht gemeint!

Zitat...sondern über einen eigenen, am Formular angebrachten Button mit dem Namen 'Schließen'.

Genau das habe ich gemeint (das Anbringen eines Buttons) - sorry, habe mich lückenhaft ausgedrückt.

ZitatInsgesamt - glaube ich - musst du dich sehr intensiv mit den Grundlagen der Access-Materie befassen...

Ja, das ist wahr! Habe erst Ende letzten November angefangen, mich mit Access auseinander zu setzen. Dazu habe ich mir Anfang Dezember das wirklich gut geschriebene Access-Handbuch von Lorenz Hölscher geholt und muss feststellen, dass vieles doch anders gestaltet werden kann, als darin beschrieben. Auch habe ich so manches darin gar nicht gefunden. Vieles muss man sich im Internet zusammensuchen. Aber mittlerweile bin ich auf gute Seiten im Netz gestoßen - auch Dank Eurer Hilfe.

Viele Grüße

Rainer