Office: (Office 2013) = Laufzeitfehler ' 2105 '

Hallo pubbl!

Ohrkester meinte:

Du sollst Abfragen zur Datenherkunft von Formularen als Abfragen abspeichern
und sie nicht in der Datenherkunft speichern.

Wolfgang

 

Vielen herzlichen Dank!

 

Die Merkwürdigkeit ist, dass ich diese SQL-Abfrage nicht "bewusst" gemacht habe ... offenbar geschah dies automatisch!

 

wenn Du den Text im Bild von #12 durchliest, dann wirst Du bemerken,
dass alle 3 Optionen Sinn machen.
Man kann aber nur eine Option auswählen und Access wählt erst einmal Option1 (INNER JOIN) aus.

 

Ja sicherlich, diese sogen. "Verknüpfungstypen" erscheinen mir als Neuling aber trotzdem ziemlich verwirrend!
Werden denn nach dem Entfernen der Verknüpfungen (Beziehungen) in der "Beziehungen-Ansicht" die SQL-Bezüge in den Formularen nicht hintenrum ebenfalls angepasst ? Oder mache ich einen Denkfehler ?

 

Den Satz muss man erstmal "auseinandernehmen" *Smilie
Beziehungen: Beziehungen/Relationen zwischen Tabellen die im Datenmodell hinterlegt werden und die referentielle Integrität berücksichtigen.
Verknüpfungen: (hier vmtl. im Sinne von JOINs) sind Beziehungen zwischen Tabellen/Abfragen innerhalb einer SQL-Anweisungen. Diese können durch die Relation der Tabellen aus dem Datenmodell automatisch gesetzt werden oder aber auch manuell durch den Entwickler.
SQL-Bezüge im Formular: Keine Ahnung was Du damit meinst...

"Von selbst" wird Access keine SQL-Anweisung in eine Datenherkunft eintragen; dort wird vom Assistenten ggf. eine Tabelle oder Abfrage beim erstellen des Formulars eingetragen. Wenn nachträglich auf die ... neben der Datenherkunft geklickt wird, wird evtl. eine Abfrage erzeugt; deren SQL-Anweisung landet dann ggf. in der Datenherkunft; das empfinde ich nicht als "automatisch" da es nur durch Aktion des Entwicklers erfolgt und darauf auch mehrfach von Access hingewiesen wird *wink.gif*

 

In meinem Hauptformular habe ich noch keine Abfragen integriert nur die Eingabefelder aus Tabellen eingefügt (es sei denn, es handelt sich bereits um eine Abfrage) - deshalb bin ich etwas verwirrt. Es ist wahr das Access von selbst darauf hinweist, in welcher Beziehung die einzelnen Tabellen miteinander stehen sollen, verwirrend finde ich nur, dass die Bezüge nicht sichtbar sind wie eben in der Beziehungen-Ansicht.

Tut mir leid für meine mangelnde Fachkenntniss - sobald ich das Datenbankmodell ein wenig besser verstehe, werden meine Fragen oder Aktionen beim Erstellen von Formularen klarer ...
Bis dahin hoffe ich auf ein wenig Nachsicht
Danke :-)

PS: Bitte nicht Antworten - Du hast ja bereits in #21 alles erklärt - Danke!

 

----------------

 

\@pubbl:

Ich hoffe, dass Du nicht die Smileys von CptChaos übersehen hast.
Ein Datenbankmodell ist eigentlich das Tabellenmodell einer Datenbank.
Die Tabellen einer relationalen Datenbank müssen gewissen Normen folgen.
Sie bestehen meistens aus Stammdatentabellen und Geschäftsdatentabellen,
auch Bewegungstabellen genannt.
Sowohl die Stammdaten-, als auch die Bewegungsdatentabellen müssen !!!
Schlüsselfelder bekommen, über welche die einzelnen Tabellen dann sinnvoll sich gegenseitig kennenlernen und gegenseitig agieren und reagieren.
Das sind der Primärschlüssel in jeder Tabelle und zusätzlich der Fremdschlüssel in Tabellen, welche zu diesen Primärschlüsseln eine Beziehung haben. Diese Schlüsselfelder sollten überhaupt nix mit den eigentlichen Daten zu tun haben (meine Empfehlung).
Bei der Erstellung einer DB feilt man bis zu mehreren Wochen !!! lang an diesem Tabellenmodell, wobei das Beziehungsfenster das Hauptbetrachtungsfenster sein wird.
Davor aber schreibt man sich auf Papier zusammen, was man denn als
Auswertungen aus einer solchen DB haben will.
Daran orientiert sich dann der Aufbau des Tabellenmodells einer DB.
Zwischendurch baut man sich über den Formularassistenten auch mal Formulare, um die Zusammenhänge manchmal besser zu verstehen.
Danach verwirft man diese Formulare wieder und verfeinert das Tabellenmodell.
Wenn das Tabellenmodell fertig ist, erstellt man die Abfragen und testet mit
ihnen, ob die grundsätzlichen Auswertungswünsche schon mal grob realisierbar sind.
Erst dann fängt man an, die Formulare und Berichte zu gestalten.
Die Formulare und Berichte sind nix anderes, als Formen mit ausgestanzten
Öffnungen, welche den Feldern einer Tabelle oder Abfrage zugeordnet werden. Dazu wird das Formular/Bericht an die Tabelle/Abfrage gebunden
und den Ausstanzungen die Tabellen-/Abfragefelder zugewiesen.
Dadurch kann man die Daten grafisch etwas optimieren.
Also müssen erst die Tabellen und Abfragen fertig sein, bevor Formulare sinnvoll sind.
Zusätzlich bietet dann Access auch noch die VBA-Programmiersprache für
die Formulare/Berichte an...usw.
Tabellen sind prinzipiell nicht mit Excel vergleichbar und strunzdumm.
Sie können ausser Daten aufnehmen und abgeben gar nix.
Am besten schaut man sich die nach der Entwicklung einer DB nur noch ausnahmsweise in einer Datenansicht an.
Intelligent werden sie erst, wenn man sie in Abfragen verwaltet.
Plötzlich kann man sortieren, filtern, berechnen usw.
Diese Abfragen übernimmt man dann als Datenherkunft von Formularen bzw.
Formularen bzw. für weitere Auswertungskombinationen.
Hoffentlich half dieser kurze Exkurs.

 

Vielen Dank, Ihr seid feine Leute, solche Geduld ist nicht selbstverstänlich! :-))

 

Hallo Ohrkester - Eine Frage habe ich noch, Deine Empfehlung ist, dass die Schlüsselfelder (Primärschlüssel ?) nichts mit den eigentlichen Daten zu tun haben.

Momentan habe ich z.B. die PersonalNr als Primärschlüssel für die Personen-Tabelle definiert - würde das jetzt bedeuten ich soll diese "ersetzten" durch eine "neutrale" Zahl oder einen Autowert und diese neutrale Zahl als Primärschlüssel nehmen ?

Wenn dem so ist, kann dann die Zuordnung PersonalNr. und Abfragen und Zuordnungen für andere Tabellen trotzdem funktionieren?
Ich spreche hier vom Tabellen-Modell (Verknüpfungen / Beziehungen (DB-Tools). Ein Primärschlüssel soll doch identifizierbar und eindeutig sein. Ein Autowert ist doch immer inkrementell - nicht ?

Oder hat das eine nicht viel mit dem anderen zu tun ?
Danke

 

Die Personalnummer wird vmtl. (ähnlich wie eine UserId in einem Windowsnetzwerk) eindeutig sein und bleiben; wenn das gewährleistet ist, würde ich sie auch als Primärschlüssel für eine Personentabelle verwenden.

Habe ich in vielen Anwendungen genau so umgesetzt; zumal es hier in meiner Umgebung so ist, dass die Personalnummer auch der Windows-Login ist und ich aus SAP, AD, etc. weitere Daten zur Personalnummer bekomme.

Ein weiterer/abweichender Primärschlüssel war bei mir hierfür nie notwendig.

 

Verstehe, Danke Dir

 

Ich hatte ein Problem beim Wechsel zwischen 2 Formularen, bei dem im neuen (2.) Formular ein neuer Datensatz über "DoCmd.GoToRecord , , acNewRec" angelegt werden sollte. Bei einem normalen Wechsel gab es keine Probleme - sobald ich jedoch mein 1. Formular verkleinert habe und dann das 2. Formular aufrief, erhielt ich den Fehler 2105.
ich weiss nicht, ob es jemandem hier hilft, aber ich habe einfach in der Fehlerbehandlung folgenden Code geschrieben:

Err_Form_Load:
Select Case Err.Number
Case 2105
Me.MeinErstesZuBearbeitendesFeld.SetFocus
Resume
Case Else
MsgBox Err.Number & "_" & Err.Description
DoCmd.Close
End Select
...
Und siehe da - es funktioniert. Kann mir nur nicht genau erklären warum!?!

 

Hallo,

wie wird denn das Formular geöffnet? Wenn es beim Öffnen leer ist und somit bereits auf einem neuen Datensatz steht, kann der Befehl natürlich nicht ausgeführt werden.

Wenn das passieren kann, aber kein wirklicher Fehler ist, kannst du den Fehler ignorieren - was du ja bereits tust.

Der Einfachheit halber könnte der Code dann auch so aussehen: Code: