Laufzeitfehler

[Rainer 1984]

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]

[MzKlMu]

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

[Rainer 1984]

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

[Rainer 1984]

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]

[MzKlMu]

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.

[Rainer 1984]

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

[MzKlMu]

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.

[database]

Hallo,

Ich 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.

... 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.  

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


[Anhang gelöscht durch Administrator]

[Rainer 1984]

Hallo Peter,

erstmal Danke! Ui - das ist komplex. 
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

[database]

Hallo, guten Morgen,

1. 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.

2. 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.

Habe 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

[MzKlMu]

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.

[Rainer 1984]

Hallo Peter, hallo MzKlMu,

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

@ Peter:

Welche 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

[database]

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.

Um 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

[Jonny]

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

[database]

Hallo,

Ich 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.

und 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.  

Ansonsten 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