Berechnete Felder aus Formular in Tabelle speichern

[Nordlicht33]

Hallo,
unerwartet bin ich auf das Problem gestoßen, dass berechnete Felder in Formularen nicht automatisch in der zugehörigen Tabelle/Abfrage gespeichert werden. Das verwundert mich, weil man in Abfragen, ja sogar in Tabellen problemlos und ohne VBA-Hilfe Berechnungen durchführen kann, die dann auch abgespeichert werden, während das bei Formularen so einfach nicht geht. Was ist der Grund? Denn aus meiner Sicht sind Formulare mindestens genauso der Ort, wo man Ausdrücke berechnet haben will, wie bei Abfragen und Tabellen.

Also habe ich mich belesen und herausgefunden, dass man hier eine ungebundenes Feld, dessen Steuerelementinhalt man per VBA dem gebundenen Feld zuweisen muss (so DonKar 4.11). Aber auch dieser Ansatz scheint nicht unumstritten, weil man in Foren liest man müsse diese Zuweisung da noch per Befehl updaten und auch hierfür verschiedene Methoden vorgeschlagen - also offensichtlich kein einfaches Problem!

Ich habe also entsprechen eine Prozedur verfasst, wo ich nach nach Verlassen des (ungebundenen) Feldes das Ergebnis dem gebundenen Tabellenfeld zuweisen wollte und das Ergebnis speichere. Das sieht dann so aus:

Private Sub cBtime_AfterUpdate()
    Me!Btime = cBtime
    DoCmd.RunCommand acCmdSaveRecord
End Sub

Dahinter verbirgt sich, dass ich über das Formular eine Anfangs- und Endzeit eingeben möchte, daraus die Dauer berechne und zusammen in einer Tabelle speichern möchte. Leider funktioniert das mit obiger Prozedur nicht: Das Feld Me!Btime bleibt nach dem Speichern leer! Was ist denn da wieder falsch?

Danke im voraus für Hilfestellungen

Bernd

[bahasu]

Hi Bernd,

im Anhang ein Beispiel.
Im ersten ungebundenen Feld wird eine Zahl eingetragen, die beim Ereignis "Beim Verlassen" dem nächsten Feld (gebunden) hinzuaddiert wird.

Vielleicht hilft das Beispiel zum Verständnis.

Harald

[Anhang gelöscht durch Administrator]

[Nordlicht33]

Harald,
ganz herzlichen Dank für die Beispieldatei. Hat mir unheimlich geholfen das richtige Vorgehen zu verstehen und zu üben!
Also Berechnungen zu Formularen über VBA machen und nicht in den Steuerelementen des Froms ist die Botschaft! Danke!

Aber noch 2 Nachfragen:

1. Warum hast Du in dem Beispiel Me.Feldname  statt Me!Feldname verwendet? Besonderer Grund oder kann man beides machen?

2. Nimmt man als Variablenbezeichnungen in  Variablennamen aus dem Eigenschaftsfenster des VBA-Editor oder die Feldnamen in Access? Die können ja unterschiedlich sein! Wenn man die Feldnamen in Access ändert, bleiben die alten Namen im VBA Editor ja erhalten. (Seltsam eigentlich). Ich habe auch den eindruck, dass es egal ist, was man nimmt. Kann das sein?

Gruß
Bernd

[MzKlMu]

Hallo,

Was ist der Grund? Denn aus meiner Sicht sind Formulare mindestens genauso der Ort, wo man Ausdrücke berechnet haben will,

Daer Grund ist, dass es im Regelfall überflüssig ist berechnte Felder zu speichern. Das macht man in einer Datenbank nicht. Es verstößt auch gegen die Normalisierung. Daher ist das auch nicht vorgesehen.
Im konkreten Fall würde man die Dauer in einer Abfrage als berechnetes Feld machen. Das Speichern der Dauer ist völlig überflüssig.
Es ist auch fehlerträchtig, weill Du immer dafür sorgen musst, dass berechnet wird und der Wert auch in die Tabelle übernommen wird. Eine Abfrage dagegen ist automatisch immer aktuell. Da man ohnehin nicht auf eine Tabelle direkt zugreifen sollte, sondern immer über eine Abfrage entsteht Dir kein Nachteil. Bei vielen Datensätzen ist sogar der Zugriff auf die Daten über eine Abfrage schneller als mit der Tabelle direkt.

[bahasu]

Hi Bernd,

1. Warum hast Du in dem Beispiel Me.Feldname  statt Me!Feldname verwendet? Besonderer Grund oder kann man beides machen?

Beides ist möglich. Puristen bevorzugen die Version mit !
http://www.access-entwicklerbuch.de/2007/index.php?page=buch&bookpage=Kap_09/02_04.html
"Den Punkt verwendet man immer, wenn das nachgestellte Element ein Access-internes Objekt ist, das Ausrufezeichen kommt bei nachgestellten benutzerdefinierten Elementen zum Zuge."

Ich verwende vielfach lieber den Punkt, da ich dann bei der Eingabe im VBA-Editor sofort überprüfen kann, ob ich den Feldnamen korrekt geschrieben habe (erwarte ich z.B. einen Namen mit einem großen Buchstaben und bleibt der im VBA-Editor klein, habe ich einen Eingabefehler gemacht).

2. Nimmt man als Variablenbezeichnungen in  Variablennamen aus dem Eigenschaftsfenster des VBA-Editor oder die Feldnamen in Access? Die können ja unterschiedlich sein! Wenn man die Feldnamen in Access ändert, bleiben die alten Namen im VBA Editor ja erhalten. (Seltsam eigentlich). Ich habe auch den eindruck, dass es egal ist, was man nimmt. Kann das sein?

Um im VBA mit den Steuerelementen des Formulars zu arbeiten, verwendet man den Namen, der im Entwurfteil des Formulars bei der Steuerelement-Eigenschaft "Name" (siehe Reiter "Andere") hinterlegt ist.
Die Namen von public und private Variablen sollten so sein, dass man sie nicht mit denen der Formular-Steuerelemente verwechselt. Hoffentlich hatte ich die Frage richtig verstanden.

Harald

[Nordlicht33]

Hi Harald,
erneutes Dankeschön für die Hinweise!

zu 1)
Habe auch gemerkt, dass das mit dem "." als Trennungszeichen hilfreich ist, weil dann den VBA-Editor zur Überwachung auf Schreibfehler nutzen kann. Ich gebe auch im Editor gerne nur in Kleinbuchstaben ein, da man dann sehen kann, ob reservierte Wörter "erkannt" werden.

zu 2:)
Bist Du da sicher? Ich habe nämlich gerade in der Tabelle einen Feldnamen geändert. Dadurch ging im zugehörigen Formular der Steuerelementinhaltsbezug verloren, den ich dann per Hand neu setzen musste. Der alte Name des Formularelementes (Reiter Andere) blieb aber erhalten und wurde so auch weiter im Eigenschaftsfenster des VBA-Editors (links unten) weiter geführt. Erst als ich auch diesen Namen in den geänderten Namen abgeändert habe, war dder Feldname im Eigenschaftsfenster des VBA-Editors sichtbar. Dessen ungeachtet kann ich über Me!steuerelementname in VBA damit arbeiten (wenn ich da beim Probieren nichts übersehen habe).

[MzKlMu]

Hallo,
falls Du es übersehen hast (#3), das Speichern ist vollständig überflüssig, im Gegenteil es verstößt gegen die Normalisierungsregeln.
In einer Datenbank wird immer berechnet wenn der Wert benötigt wird. Das Speichern macht nur bei sehr großen DBs aus Performancegründen Sinn.

Warum willst Du speichern, welche Notwendigkeit siehst Du da?

Und beachte auch die Hinweise in #3 zur Verwendung von Abfragen.

[bahasu]

Hi,

zu 2:)
Ich habe nämlich gerade in der Tabelle einen Feldnamen geändert. Dadurch ging im zugehörigen Formular der Steuerelementinhaltsbezug verloren, den ich dann per Hand neu setzen musste.

Korrekt: in der Steuerelementeigenschaft "Steuerelementinhalt" (im Reiter "Daten") ist das anzupassen.

Harald

[Nordlicht33]

Hi MzKlMu,
danke für die Hinweise. Du hast völlig recht und ich werde das auch so befolgen. Schade, dass ACCESS als Entwicklungsumgebung einen hier nicht stärker "erzieht".
Das mit dem Speichern habe ich irgendwo im Internet gefunden, aber mittlerweile auch gelernt, dass da viel Mist im Internet steht, was später nur Zeit und Ärger versursacht.
Deshalb fühle ich in diesem Forum auch gut aufgehoben, weil ich von euch Hinweise bekomme, die Hand und Fuß haben und mit denen man was lernt.
Ich bin da schon sehr dankbar für!

Gruß
Bernd

[MzKlMu]

Hallo,

Schade, dass ACCESS als Entwicklungsumgebung einen hier nicht stärker "erzieht".

Access erzieht schon. Immer wenn Du was scheinbar einfaches einbauen willst und Du stellst fest, dass es nicht einfach ist, musst Du darüber nachdenken ob es sinnvoll ist. Eine Datenbank erfordert einen völlig anderen Tabellenaufbau als Excel. In Excel einen Mittelwert aus 5 Spalten zu berechnen ist eine Kleinigkeit. In Access geht das nicht über Spalten, da muss ein großer VBA Aufwand betrieben werden um das zu tun. In einer korrekt aufgebauten DB braucht man keinen Mittelwert über Spalten.
Das mit dem Mittelwert war jetzt nur ein Beispiel, das mir gerade eingefallen ist. Daher wenn etwas nicht einfach geht, muss das Datenmodell hinterfragt werden.

Übrigens, auch bei DonKarl 4.11 steht, dass man berechnete Werte im Regelfall nicht speichern sollte.

[Nordlicht33]

Hi,
ich brauche noch mal Hilfe, weil ich im Moment völlig durchgedreht bin und gar nichts mehr geht

1. Ich habe jetzt die Zeitdauern in der Abfrage (qryFluege) berechnet, kann diese Felder jedoch nicht als Datum/Zeit formatieren.  Datum/Zeit wird für die Formatierung des Feldes nicht angeboten. Das ist aber so nicht angemessen interpretierbar. Wo liegt der Fehler?

2. Ich kann in der Abfrage keine Datensätze mehr anfügen! Wenn ich versuche einen Datensatz anzufügen, bekomme ich die Fehlermeldung "Das Microsoft Access Datenbankmodul kann in der Tabelle tblFlart keinen Datensatz mit passenden Schlüsselfeldern Flart finden". Dieser Fehler wandert auch noch! Ursprünglich trat er auf bei Eingabe im Feld "Flugart" (Nachschlagefeld). Jetzt tritt er plötzlich schon bei Eingabe von "FI" (Nachschlagefeld) auf. Mir ist klar, dass dieser Fehler was mit den Tabellenstrukturen und Schlüsselfeldern zu tun hat - aber ich bekomme es nicht auf die Reihe! Offensichtlich habe ich was Grundsätzliches nicht verstanden! Traurig macht mich auch, dass ich in den vergangenen Tagen mehrfach Probeeingaben gemacht hat, wo der Fehler nicht auftrat (hatte ich jedenfalls den Eindruck). Ich habe deshalb die DB in abgespeckter Form als Anlage hochgeladen. Wenn ihr da mal einen Blick drauf werfen könntet.

Gruß
Bernd


[Anhang gelöscht durch Administrator]

[MzKlMu]

Hallo,

Zu 1)
in einer Abfrage formatiert man keine Felder. Dort ist das Format bedeutungslos. Formatiert wird das Feld im Formular/Bericht. Dort kannst Du auch das gewünschte Format (hh:nn:ss) direkt eintragen. Es muss nicht angeboten werden. Gibt es bei dieser Dauer mehr als 24 Std.? Ich denke nein, oder?

Zu 2)
In einer Abfrage gibt man keine Daten ein, weil genau das passiert was Du jetzt hast. Dateneingaben erfolgen immer über ein Formular.
Weiterhin sind Deine Beziehungen falsch.

Offensichtlich habe ich was Grundsätzliches nicht verstanden!

Genau, Beziehungen erfolgen immer über die nummerische ID und nicht über Textfelder. Daher wären erst mal die Beziehungen zu überarbeiten. Weiterhin solltest Du unbedingt alle Nachschlagefelder in den Tabellen direkt entfernnen. Nachschlagefelder verhindern den sauberen Aufbau einer DB. Nachschlagefelder (Kombifelder) verwendet man nur in Formularen.

Bitte beschreibe mal, mit welchen Feldern die Dauer berechnet werden soll.
Ich komme aus den Abfragen nicht recht mit.

Hier besteht nach meiner Auffassung noch ziemlicher Bereinigungsbedarf, so kannst Du nicht weitermachen.
Im Anhang mal die Beziehungen wie diese sein sollten. Das ist aber nicht vollständig.

Beschreibe mal mit welchen Feldern die verschiednen Dauern berechnet werden, ich komme da bei den Abfragen nicht recht raus.
Und beschreibe mal die einzelenen Aufgaben der Tabellen.

[Anhang gelöscht durch Administrator]

[Nordlicht33]

Hallo MzKlMu,
danke, dass Du Dir das ansehen willst.

Also: Die Dauern berechne ich in der Abfrage "qryFluege" aus den Feldern Btime = [tON] - [tOFF] und Airtime = [tLDG] - [tTO], die Dauern sind hh:mm und <24h.

Die Nachschlagefelder habe ich benutzt, weil in mehreren Lehrbüchern dieses Feature von Access besonders gelobt wird und der Vorteil betont wird, man brauche dann die Kombinationsfelder in den Forularen nicht immer ieder neu zu erstllen, weil die Verknüpfung quasi "vererbt" wird. Das hat mir eingeleuchtet und deshalb habe ich das noch einmal neu so aufgebaut.

Die Beziehungsstruktur ist so aufgebaut, dass eine Tabelle (tblFluege) Felder der anderen Tabellen als Fremdschlüssel nehmen soll. Komplexer soll die Beziehungstrukturen nicht werden, also keine mehrstufigen Beziehungen o.ä. Die als Fremdschlüssel genutzten Felder der "Neben"-Tabellen sind in der Tat nicht immer numerische Felder. Das habe ich deshalb gemacht, weil es sich hierbei um Felder handelt, die Lüzel darstellen, die ohnehin immer eindeutig sein sollen; d.h. Duplikate sollen hier nicht auftreten. Deshalb habe ich mir gedacht, kann ich die auch gleich als Schlüssel verwenden, weil lt. Lehrbuch ja auch alphanumerische Felder benutzt werden können - und ich nutze dann die Eigenschaft von Access aus, zu prüfen, ob das Kürzel schon verwendet wird.

Dieser Felder solen in der Tat so etwas wie Nachschlagefelder sein, wo ich in separat gepflegten Tabellen die Schlüssel (Kürzel) nachschlage und in die Tabelle eintrage. Das reicht mir erst einmal als Anwendung. Ich weiß, das Access da mehr kann, aber das brauche ich erst einmal nicht.

Lass mich aber hier auch noch mal meinen Ärger loswerden, dass Access nicht erzieht! Ich glaube Dir sofort, dass man Formate nicht in Abfragen, sondern in Formularen oder Berichten defineiren soll. Aber wo steht das? Wenn ich in den Abfrage-Editor von Access schaue, werden mir von Access dort verschiedenste Möglichkeiten der Formatierung angeboten. Ich kann Felder als Währung, Prozent- und Exponentialzahlen formatieren, aber nicht als Datumsfeldern; bei anderen Feldern geht das wieder. Wenn Access Formatierungen eben ur bei Formularen und Berichten erlauben würde, dann wäre die Sache klarer; wenn Access Berechnungen nur in Abfragen zuließe - wäre die Sache klarer. Wenn Access keine Nachschlagefelder anbieten würde, sondern Kombinationsfelder nur in Formularen - ware die Sache klarer. Ic habe in den letzten Wochen viele Bücher über Access gelesen, habe versucht die Beispiel dort nachzuarbeiten und nachzuvollziehen. Dabei habe ich viel über Features und Verfahrensweisen gelernt, aber offensichtlich wenig über Grundsätze. Das schmerzt.

Nimms mir nicht übel. Ist ja nicht gegen Dich. Im Gegenteil! Ich bin froh mit Dir einen Gesprächspartner gefunden habe, der mir Klarheit verschafft. Sonst wäre ich vielleicht schon abgedreht. Aber ich kann mich ja nicht nur auf Dich abstützen.

Gruß
Bernd   

   

[MzKlMu]

Hallo,
die Nachschlagefelder sind ohne wenn und aber zu entfernen. Die sind in Tabellen so überflüssig wie ein Kropf und fehlerträchtig. Die Bücher lernen da durchweg Unsinn. Verlasse Dich auf das Forum.
Siehe hierzu:

http://dbwiki.net/wiki/Access_Anf%C3%A4nger:_Die_Nachteile_von_Nachschlagefeldern

Deine Beziehungstruktur ist definitv falsch. Du kannst auch mit der von mir im Bild vorgeschlagenen Struktur alles machen was Du vorgesehen hast. Ohne Einschränkung. Alphanumerische Felder sind als Schlüssel ungeeignet, trotz Lehrbuch. Und um zu prüfen, ob das Kürzel schon verwendet wird, muss es kein Schlüsselfeld sein. Dazu wird das Feld indiziert ohne Duplikate, das hat den gleichen Effekt.

Access ist nun mal ein Programm das man lernen muss.

Ich baue Dir das gern um, dass es funktioniert, aber dazu solltest Du erst mal meine Frage nach der Bedeutung der einzelnen Tabellen beantworten.

Und beschreibe mal die einzelnen Aufgaben der Tabellen.

[Nordlicht33]

Hi,
dann will ich doch mal gleich loslegen:

Insgesamt will ich mit dieser Access Anwendung das Flugbuch unseres Vereins führen; d.h. ich will in einer Datenbank, alle Flüge einheitlich erfassen und daraus die Vereinsmitglieder  mit Berichten versorgen, wer welche Flüge durchgeführt hat.
Nebenziele sind: die Schreibweise zu vereinheitlichen, also dafür sogen, dass einheitliche Abkürzungen verwendet werden und die Flugzeitenberechnung automatisiert wird, weil beim händischen Ausrechnen der Flugzeiten und ihrer Aufsummierung immer wieder Fehler gemacht werden.

Die Haupttabelle ist die Tabelle ,,tblFluege". Dort soll eingetragen werden, wer, wann mit welchem Fluglehrer wohin geflogen ist, wie lange er geflogen ist, was Ziel dieses Fluges war und wie der Flug abrechnungstechnisch behandelt werden soll.

Die übrigen Tabellen sind Hilfstabellen, die zur Haupttabelle in einer 1:n Beziehung stehen (wenn ich das richtig verstanden habe) und zusätzliche Angaben verwalten.

Die Tabelle ,,tblSPdaten" verwaltet die Piloten und Flugschüler. Hier sollen neben Kontaktdaten festgehalten werden, wer aktiv ist und wer gemeldet ist. Der Bezug zur Haupttabelle geht über den Primärschlüssel ID zum Fremdschlüssel SP der Haupttabelle.

Die Tabelle ,,tblFIDaten" verwaltet die Fluglehrer. Neben Kontaktinformationen auch hier die Angabe wer aktiv ist. Da die bei uns über ein Kürzel bekannt sind, habe ich das Feld FIID (alphanumerisch) als Fremdschlüssel für die Haupttabelle bisher benutzt.

Die Tabelle ,,tblFlart" soll die Kategorie des Fluges, also die Abrechnungsart des Fluges verwalten. Hier habe ich den Primärschlüssel der Tabelle (fCode)als Fremdschlüssel in der Haupttabelle (Flugart) definiert.   

Die Tabelle ,,tblAirfields" beschreibt die angeflogenen Flugplätze. Flugplätze sind weltweit einheitlich über einen 4stelligen Buchstabencode  (ICAOCode) definiert, den ich entsprechend als Fremdschlüssel ,,Dest" in der Haupttabelle verwalte.

Die Tabelle ,,tblSorties" verwaltet Angaben über den ,,Sinn" des Fluges. Das ist in der Hauptabelle eigentlich ein einfaches Textfeld, das in der bisherigen Papierversion des Flugbuches auch vielfach leer bleibt, wenn der Flug keinen besonderen ,,Sinn" hat; aber manchmal auch ergänzende Hinweise enthält, worum es da ging. Die Tabelle ,,tblSorties" deckt dieses Spektrum allerdings nicht vollständig ab und soll es auch nicht.  Die Tabelle ,,tblSorties" enthält einheitliche Bezeichnungen für Flugübungen mit Flugschülern (Sortiecode).  Diese sollen für Schulflüge (und nur dafpr) nicht beliebig beschrieben und vermerkt werden, sondern nach dem Kurzbezeichnungen der  Tabelle ,,tblSorties" erfolgen. Deshalb habe ich den Sortiecode als Fremdschlüssel für Sortie definiert.
Das Problem bei dieser Tabelle ist, dass die Inhalte sich laufend verändern. Die Bezeichnungen und Kürzel sind hier also nicht konstant und eindeutig, sondern ändern sich im Zeitverlauf. Wir werden in diesem Jahr z.B. wieder eine Veränderung der behördlichen Vorschriften haben, die die Ausbildungsinhalte neu strukturiert. Insofern werden sich Bezeichungen und Tabellenlänge ändern. Auch in der Folgezeit sind laufende Änderungen zu erwarten, die heute nicht voraussehbar sind. Insofern wird der Schlüssel nie eindeutig sein. Das macht aber auch nichts, weil wir diese Tabelle auch nicht nutzen wollen, um eindeutig auf eine andere Tabelle zu verweisen, Das soll wirklich eine Nachschlagtabelle sein, mit der man aktuell definierte Kürzel in die Haupttabelle reinholt und nicht ,,freihändig" reinschreibt. Jenseits des Schulbetriebs kann das Feld Sortie sehr wohl ,,freihändig" benutzt werden etwa: ,,War mit Karl auf Sylt" Insofern ist diese Tabelle beziehungstechnisch anders zu handhaben. Mehrdeutigkeiten sind hier unumgänglich.

Dies zu den Tabellen. Ich habe versucht, dies insgesamt als Grafik unten darzustellen.

Ergänzend wäre noch anzumerken, dass wir die Flugzeiten je Flug automatisch berechnen wollen und auch die Gesamtflugzeiten und Gesamtzahl der Landungen automatisch berechnen wollen, weil da in der Papierform zahlreiche Rechenfehler passieren, die nicht lustig sind. Deshalb sollen unsere Piloten gar keine Chance haben, das selbst auszurechnen.

Soweit! Ich hoffe das reicht Dir erst mal als Info, die Beziehungen zu strukturieren. Für Nachfragen bin ich auf Stand-by.

Zu meinen Kenntnissen ist anzumerken, dass ich mich mit Office gut auskenne und insbesondere in den letzten Jahren viele Erfassungen und Berechnungen in EXCEL gemacht habe. Vor vielen Jahren habe ich auch recht umfangreich in PASCAL und FORTAN programmiert. Dadurch habe ich Programmierkenntnisse, die aber aus einer anderen Welt stammen.


[Anhang gelöscht durch Administrator]