Seite 2 von 4

Re: Abhängige Listenfelder machen Probleme

Verfasst: Do, 31.05.2012 20:09
von paradigma
Hallo
ist der Aufabau für das dritte Listenfeld gleich (also K3 zeigt nur das an was zu K2 gehört)?
Sind das in dem Falle 2 Makros oder muss das in das eine dann rein?
Du brauchst sicher noch ein zweites Makro, damit im Listenfeld 3 nur jene Einträge erscheinen, die zum gewählten Eintrag im Listenfeld 2 passen.

Im Unterschied zu Listenfeld 1 und Listenfeld 2 musst du Listenfeld 3 noch zusätzlich an das entsprechende Tabellenfeld anbinden. Es müsste das Feld K3-ID sein, das du als Fremdschlüssel in deine Artikeltabelle einbauen musst (dort möchtest du ja Daten erfassen, wenn ich das richtig verstanden habe).

Gruss

Beni

Re: Abhängige Listenfelder machen Probleme

Verfasst: Do, 31.05.2012 20:14
von Ignis Pugnatur
Ja hast du ....
Also eigentlich das selbe Makro, ausser dass die Spalten-, Feld- und Tabellenbezeichnungen nicht von K1 zu K2 verweisen sondern von K2 nach K3.
Wenn ich nun das erste Makro mal in Gang bekäme wäre ich glücklich .....
Im Moment hält mich Besuch und das Abendessen vom "arbeiten" ab ....
Aber ein Päuschen tut auch gut und morgen ist ja auch wieder arbeiten angesagt.
Mal sehen wie lange ich heute noch durchhalte oder besser ...
wann ich in Ruhe wieder ran kann.

Erst mal Danke ..... mal sehen ob ich das hin bekomme.

LG Patric

Re: Abhängige Listenfelder machen Probleme

Verfasst: Do, 31.05.2012 23:01
von Ignis Pugnatur
So sieht der Code nun bei mir aus.
Ich denke aber dass es an den Folgend rot markierten Stellen liegt dass das nicht so tut wie es soll .....

Sub LiA_EAN_Artikelliste
Dim sSql(0) as String
' GlobalScope.BasicLibraries.LoadLibrary("XrayTool")
oDoc = ThisComponent
oForm = oDoc.Drawpage.Forms.getByName("MainForm")
oAuswahlGruppe = oForm.getByName("Lif-K1")
sGruppe = oAuswahlGruppe.CurrentValue
oAuswahlArtikel = oForm.getByName("Lif-K2")
sSql(0) = "SELECT ""Li-K2"".""Gruppe"", ""Li-K2"".""K2-ID"", ""Li-K1"".""Hauptkategorie""" &_
"FROM ""Li-K2"", ""Li-K1"" WHERE ""Li-K2"".""K1-ID"" = ""Li-K1"".""K1-ID""" &_
"And ""Li-K1"".""Hauptkategorie"" Like '%" & sGruppe & "%'"
oAuswahlArtikel.ListSource() = sSql()
oAuswahlArtikel.refresh()
End Sub

Ich vermute mal, dass das die Namen der Listenfelder sein sollten.
Allerdings habe ich grade keinen Nerf mehr und so langsam ruft das Bett damit ich morgen auf Arbeit nicht von Scripten verfolgt werde .....
Morgen Abend bin ich wieder da und werde mal versuchen das zu ersetzen, mal sehen was passiert.
Schlimmer kann es kaum werden ^^.
LG und Gute Nacht
Patric

EDIT:
Halt Stop - Komando zurück ...
Man sollte auch mal speichern und dann versuchen .... Sorry
Nun geht das ....

Ich werde morgen den zweiten Code für K2 zu K3 machen und dann Bericht erstatten.
Es lag wirklich an dem von dir angesprochenen Name der bei mir MainForm heißt.
Ich werde morgen wieder "Meldung" machen.

Ach ja - Einleitend schrieb ich was von Datum soll automatisch rein ....
Das hab ich auch noch nicht raus .... Phuuuu - na mal sehen
In Accsess war das JETZT() - mal sehen wie das hier geht.

Jetzt aber gute Nacht und bis morgen - Danke für eure bisherige Hilfe.
Patric

Re: Abhängige Listenfelder machen Probleme

Verfasst: Fr, 01.06.2012 07:56
von RobertG
Hallo Patric, hallo Beni,

ich will nur noch einmal zwei Gedanken zu der Sache aufgreifen, über die ich zumindest mir vorher klar werden würde:
Es gibt die folgenden Beziehungen:
Lebensmittel > Fisch > Tiefkühl
Lebensmittel > Tiefkühlprodukte > Fisch
... und das sind nicht die einzigen dieser Art, die in den beiden unteren Kategorien umtauschbar sind.
In dem Beispiel sind im Moment die Felder in den beiden oberen Tabellen noch unterschiedlich. Ab der 3. Tabelle finden aber laufend Verdoppelungen statt.
Sobald in der Tabelle 2 die erste Verdoppelung stattfindet geht der angedachte Makrozugriff nicht mehr. Das Makro greift auf CurrentValue zu. Das ist der Wert, der angezeigt wird. Ist der nicht eindeutig, dann ist auch die Auswahl in dem folgenden Listenfeld nicht eindeutig.
Irgendwie muss der Zugriff nicht über den angezeigten Wert sondern über den Primärschlüssel erfolgen. Dieser Schlüssel steckt in der Regel in dem Feld, das ein Listenfeld an die darunterliegende Tabelle weitergibt. Und darauf kann ich nur zugreifen, wenn ich den Inhalt der Tabelle abspeichere. Ich brauche also irgendwo eine Speichermöglichkeit für das Listenfeld1 und das Listenfeld2, bevor ich im Listenfeld3 das auswähle, was ich eintragen will.

Gruß

Robert

Re: Abhängige Listenfelder machen Probleme

Verfasst: Fr, 01.06.2012 14:29
von Ignis Pugnatur
Danke für deinen Rat.
Ich war heute morgen auf arbeit und da wurde mir gesagt, dass ich nicht arbeiten muss, (Überstunden abbummeln befohlen ^^) und kann mich daher nun der Liste widmen.

Wie oben erwähnt gebe ich dir Grundsätzlich recht.
Die Grundstruktur war noch etwas durcheinander, aber ich bin am sortieren.
Das mache ich wegen der Übersicht erst mal in Calk.
Mal sehen ob das in LO-Base auch so geht wie in Accsess, dass man Exceldaten (Calk) importieren oder einfach kopieren kann. Sonst muss ich eben doppelt tippen.

Auch mit den Zugriffen hast du Recht, aber da habe ich schon vorgeplant.
Das Prinzip ist in Accsess ja gleich (da hatte ich diese DB ja schon).
Wenn du dir das Calkdokument angeschaut hast, dann siehst du, dass es drei Blätter hat. Auf dem dritten (und auch schon auf dem zweiten) ist ersichtlich, dass ich jedem Wert eine ID zugewiesen habe. In der zweiten und dritten Gruppe sind die IDs der jeweiligen Gruppe davor dabei. Der DB-Zugriff findet also über die IDs statt. Angezeigt wird aber der Begriff.
Dennoch danke für diesen Hinweis. Es gibt ja noch mehr User die diesen Thread ggf. interessant finden könnten und grade für Neulinge wie mich sind solche Details doch sehr interessant.
Was ich z.B. nicht wusste war die "beiläufige" Bemerkung von paradigma:
Nach dem Klick auf den OK-Button öffnet er das Macrofenster und markiert die Zeile:
oForm = oDoc.Drawpage.Forms.getByName("FormArtikel")
Natürlich habe ich alle Elemente des Macros auf meine Bezeichnungen geändert .....
Ich tippe darauf, dass der interne Name deines Formulars nicht "FormArtikel" heisst. Vermutlich heisst es "MainForm".
Formulare haben einen externen und einen internen Namen. Der externe ist der, den du am Bildschirm siehst, wenn du in Base auf Formulare klickst.
Der Interne siehst du, wenn du das Formular im Entwurfsmodus öffnest und auf den Formularnavigator klickst. Ich verwende jeweils für beide die gleiche Bezeichnung, damit ich mir nur einen Namen merken muss.
Diese Makrozeile greift auf den internen Namen zu, deshalb solltest du zuerst diesen Namen überprüfen.
Das sind genau solche "Kleinigkeiten, die große Auswirkungen haben können.

Die Tipps für die ordentliche Sortierung sind übrigens nicht mal so unwichtig. Wenn die nicht stimmt oder mehrfach doppelte Werte enthalten (auch wenn die DB dann noch geht), so macht das dann keinen Sinn mehr, da dann der Sinn dieser Arbeit und der DB verfehlt wäre.
Allein der strukturelle Aufbau einer DB ist schon mehr als nur ein Kinderspiel.
Das kann in einer richtigen Knobelarbeit enden.
Problem ist ja oft, dass man hinterher schlecht größere Änderungen machen kann ohne dabei die Grundstruktur zu schädigen.
Oft ist da eine Neuprogrammierung Sinnvoller.
Also vorher denken und nicht hinterher heulen ... :lol:

Ich bin immer der Meinung, wenn ich in solchen Foren poste ....
Dass noch andere User mit den Infos etwas anfangen können und versuche das dann gerne etwas ausführlicher zu schildern.
Wenn nun Antworten kommen die mir vieleicht nicht helfen, oder die ich schon kenne, dann heisst das aber nicht, dass andere damit nichts anfangen können.


Nun aber wieder zur DB:
Die beiden Listenfelder gehen nun .... abgesehen von den darin befindlichen Daten die noch durcheinander sind.
Ich werde da noch etwas basteln und dann die Calk & Base - Dateien hochladen.
Vieleicht können andere damit ja auch was anfangen.
Ein kleines Problem hätte ich nun aber noch (gehört eigentlich nicht hier rein).
Auch wenn schon oft behandelt .... bei mir klappt das irgendwie nicht mit dem automatischen Datum.
Kurzerklärung:
Tabelle mit Datumsfeld
Typ: Datum/Zeit: [TIMESTAMP]
Im Formular soll nun automatisch das Datum und die Uhrzeit mit in den Datensatz übernommen werden. Der Wert soll sich nicht mehr verändern sondern fest die Zeit erfassen wann dieser Datensatz erfasst wurde (ggf. noch von wem).
Schön wäre es, wenn dieser Wert auch visuell im Formular zu sehen wäre.
Am besten bei der Formularöffnung und eine aktualisierung bei jedem neuen Datensatz.
In Accsess ging das einfach unter Eigenschaften - Standartwert "JETZT()" im betreffenden Feld des Formulars.
Weis da jemand einen Rat? Das scheint in Base ja auch ein etwas komplexerer Bereich zu sein.

LG Patric

Re: Abhängige Listenfelder machen Probleme

Verfasst: Fr, 01.06.2012 18:12
von RobertG
Hallo Patric,
Ignis Pugnatur hat geschrieben: Auch wenn schon oft behandelt .... bei mir klappt das irgendwie nicht mit dem automatischen Datum.
Kurzerklärung:
Tabelle mit Datumsfeld
Typ: Datum/Zeit: [TIMESTAMP]
Im Formular soll nun automatisch das Datum und die Uhrzeit mit in den Datensatz übernommen werden. Der Wert soll sich nicht mehr verändern sondern fest die Zeit erfassen wann dieser Datensatz erfasst wurde (ggf. noch von wem).
Schön wäre es, wenn dieser Wert auch visuell im Formular zu sehen wäre.
Am besten bei der Formularöffnung und eine aktualisierung bei jedem neuen Datensatz.
In Accsess ging das einfach unter Eigenschaften - Standartwert "JETZT()" im betreffenden Feld des Formulars.
Weis da jemand einen Rat? Das scheint in Base ja auch ein etwas komplexerer Bereich zu sein.
Zum automatischen Datum bzw. Timestamp musst Du wissen, dass die Hilfe-Beschreibung seit einiger Zeit hier fehlerhaft ist. Diese Automatik hat in der grafischen Benutzeroberfläche nie funktioniert.
Es gibt einen Unterschied zwischen den Default-Werten der grafischen Benutzeroberfläche und denen der eigentlichen Datenbank. Das ist übrigens später auch für die Beziehungen gut zu wissen.
Du musst also die Default-Werte mit einem SQL-Befehl direkt festlegen:

Code: Alles auswählen

ALTER TABLE "Tabellenname" ALTER COLUMN "Datumsfeldname" SET DEFAULT CURRENT_DATE
Im LO-Base-Handbuch sind entsprechende Passagen aus der englischsprachigen Beschreibung der HSQLDB entsprechend übersetzt und ergänzt:
http://de.libreoffice.org/hilfe-kontakt/handbuecher/ - auf dieser Seite etwas nach unten scrollen. Dort gibt es die einzelnen Kapitel zum Download - Deins wäre hier das Kapitel 3 "Tabellen".
Das Handbuch findest Du aber auch zusammen mit den Beispieldatenbanken auf http://robert.familiegrosskopf.de unter dem Menüpunkt "Einführung Base".
Dieser Default-Wert wird nur dann eingetragen, wenn kein Wert im Formular eingetragen wird. Das bedeutet auch: Du siehst leider nicht vorher, welcher Wert da steht. Das ist wie mit dem AutoWert, der schließlich auch erst nach Abspeicherung des Datensatzes sichtbar wird.
Vielleicht wird ja in einer der zukünftigen Ausgaben von OO oder LO ein entprechendes Feld auf der GUI zur Verfügung stehen. Das dürfte dann aber nur den Bereich des Datums abdecken. Schließlich will niemand ein Feld in einem Formular haben, das während des Formularaufrufs bei Zeitangaben laufend den Inhalt ändert ...

Gruß

Robert

Re: Abhängige Listenfelder machen Probleme

Verfasst: Fr, 01.06.2012 18:24
von RobertG
... und hier der zweite Teil zu dem Benutzernamen.
Das war meines Wissens vor kurzem hier im Forum. Ich habe jetzt einmal schnell die Makros kopiert:

Code: Alles auswählen

SUB Umgebungsvariablen
    sUser = "unable to determine USER "
    sHostname = "unable to determine HOSTNAME"
    Select Case GetGuiType
       Case 1 ' Windows
          sUser = Environ( "USERNAME" )   
          sHostname = Environ( "COMPUTERNAME" )
       Case 3 ' MacOS
          sUser = Environ( "USER" )
          sHostname = Environ( "SHORTHOST" )
       Case 4 ' Unix
          sUser = Environ( "USER" )   
          sHostname = Environ( "HOSTNAME" )
       Case Else
          sUser = "unknown operating system - no way to find USER"
          sHOSTNAME = " no way to find out HOSTNAME"
    End Select
END SUB

SUB Benutzername_einfuegen
oDoc=thisComponent
oDrawpage=oDoc.Drawpage
REM Lage des Feldes in dem entsprechenden Formular aufsuchen
oForm=oDrawpage.Forms.getByName("Formular")
oFeld=oForm.getByName("Name")
oFeld.BoundField.updateString(Environ("USER"))
END SUB
Die erste Prozedur zeigt die Umgebungsvariablen auf, die ausgelesen werden können. Die zweite Prozedur "Benutzername_einfuegen" dient unter Linux dazu, den aktuellen Benutzernamen der angemeldeten Person an der entsprechenden Stelle des Formulars einzufügen. Noch einmal kurz zu der Prozedur: Zugriff auf das aktuell geöffnete Dokument mit oDoc. Zugriff auf die Zeichnungsoberfläche mit oDrawpage. Zugriff auf das mit dem Namen "Formular" versehene Formular. Zugriff auf das Feld mit der Bezeichnung "Name" in diesem Formular. Eintrag des Usernamens in das mit diesem Feld verbundene Datenfeld der dem Formular zugrundeliegenden Tabelle.

Gruß

Robert

Re: Abhängige Listenfelder machen Probleme

Verfasst: Fr, 01.06.2012 18:41
von Ignis Pugnatur
Danke für die Info.
Es soll keine "laufende" Uhren-Anzeige sein ....
Wozu haben die meisten denn in der Taskleiste eine Uhr? ... ... andere packen sich so ne Anzeige ja sogar als Desktop rein ....:lol:

Beispiel (so dachte ich es mir):
Formular wird geöffnet um einen Datensatz ein zu geben. Der Timestamp wird im Datumsfeld angezeigt und beim speichern mit in die Tabelle übernommen (entweder das Datum zum Zeitpunkt des öffnens des Formulars oder zum Zeitpunkt wenn der Datensatz gespeichert wird.
Für meine Zwecke kann das Datumsfeld auch unsichtbar sein (ganuso wie Autofelder für Schlüsselnummern etc.) .
Wichtig wäre nur dass der Wert in die Tabelle übernommen wird.

Wird der Datumswert ausschließlich beim speichern übernommen?
Angenommen ich möchte 10 Datensätze eingeben - Dann kann man die Felder mit der [TAB]-Taste nach der Eingabe in ein Feld in das nächste "weiterschalten".
So wie ich das bisher sah wird nach dem letzten Feld ein neuer Datensatz geöffnet und der Cursor steht im ersten Feld (eben je nach Reihenfolge der Aktivierungsreihenfolge).
Ich habe das soweit noch nicht getestet um zu sehen ob da die Daten auch übernommen werden.
Wie einleitend gesagt arbeite ich nun 5 Wochen mit Linux und nicht mal eine Woche mit Base.
Ich bin also noch einer der berühmt-berüchtigten Vollnoobs ..... *GRINS*

Patric

Re: Abhängige Listenfelder machen Probleme

Verfasst: Fr, 01.06.2012 18:55
von RobertG
Hallo Beni,
Ignis Pugnatur hat geschrieben: Wird der Datumswert ausschließlich beim speichern übernommen?
Angenommen ich möchte 10 Datensätze eingeben - Dann kann man die Felder mit der [TAB]-Taste nach der Eingabe in ein Feld in das nächste "weiterschalten".
So wie ich das bisher sah wird nach dem letzten Feld ein neuer Datensatz geöffnet und der Cursor steht im ersten Feld (eben je nach Reihenfolge der Aktivierungsreihenfolge).
Die Daten werden beim jedem Abspeichern geschrieben. Du speicherst einen Datensatz in die Datenbank, wenn Du den Datensatz (mittels Tabulator z.B.) verlässt.
Machst Du die ganze Dateneingabe in einer Tabelle (oder einer Abfrage oder einem Tabellenkontrollfeld), so siehst Du bereits die vorher erstellten Datensätze. Dort wird dann auch das abgespeicherte Datum sichtbar.
In der Beispieldatenbank für das Base-Handbuch habe ich das Anzeigen des Datums so gelöst, dass das Datum über eine separate Tabelle vorgegeben wurde. Das heißt, dass ich meine eigentliche Dateneingabe in einem Subformular mache und in dem Hauptformular eine Tabelle mit z.B. einem Datumsfeld habe, das immer wieder mit dem momentanen Standardwert gefüttert wird.
Du könntest natürlich auch mittels Makro einen entsprechenden Wert in das Formular schreiben. Gerade bei Datumseingaben ist das aber immer etwas tricky, da Du zwischen 3 Stühlen sitzt: Datum nach Benutzeroberfläche, Datum nach Basic-Format und Datum nach SQL-Format.
Ich versuche zuerst einmal möglichst den Weg zu gehen, den mir die Datenbank bietet. Für andere mag das ein falscher Ehrgeiz sein. Für mich ist das Denksport.

Gruß

Robert

Re: Abhängige Listenfelder machen Probleme

Verfasst: Fr, 01.06.2012 21:06
von Ignis Pugnatur
Hmmmm....
Ich verstehe das grade nicht ganz.
ID in Tabelle ist CURDATE() in der Abfrage und wird in dem Fall im augenblicklichen Datensatz angezeigt und an die ander Tabelle zurückgegeben.
Könnte man das CURDATE() nicht auch direkt als Standartwert setzen?
Vermutlich würde es dann nicht gleich mit angezeigt.
Irgendwie verstehe ich auf die schnelle nicht warum das ID-Feld der ersten Tabelle Ja/Nein ist und in der Abfrage mit einem CURDATE() hinterlegt wird.
Vermutlich ist die Datumsformatierung auch erst in dem Formular für die Anzeige hinterlegt.
Sorry, habe nur einen schnellen Blick rein geworfen .....
Muss mir das noch in Ruhe anschauen.
Ich bastle immer noch an den Datenlisten für die drei Listenfelder .....

Re: Abhängige Listenfelder machen Probleme

Verfasst: Fr, 01.06.2012 22:28
von RobertG
Hallo Beni,

Mit CURDATE() kann das aktuelle Datum abgefragt werden. Eine Abfrage kann ich aber nur konstruieren, wenn ich einen Tabelle anspreche und diese Tabelle auch einen Datensatz beinhaltet. Das habe ich in vielen meiner Datenbanken sowieso, nämlich eine Tabelle, mit der ich z.B. Daten filtere. Dadurch, dass der Primärschlüssel ein Ja/Nein-Feld ist, stelle ich sicher, dass maximal zwei datensätze gespeichert werden. Der, den ich nutze, ist der Datensatz mit "Ja". Gebe ich nun

Code: Alles auswählen

SELECT CURDATE() FROM "Tabelle" WHERE "ID" = TRUE
ein, so erzeuge ich in einem Datensatz die Darstellung eines aktuellen Datums.
Wie oben geschrieben: Dafür muss ein Datensatz existieren, Das geht nicht in einem Datensatz, den ich gerade eingebe.
Danach bediene ich mich der Verknüpfung von Hauptformular und Unterformular. Das Hauptformular liest den Inhalt der Abfrage aus und gibt das aktuelle Datum an das Datumsfeld des Unterformulars weiter. Im Unterformular steht also bereits das aktuelle Datum als Voreingabe.
Schönheitsfehler, der durch ein Formular neben dem Hauptformular geklärt werden kann: Das Unterformular zeigt natürlich nur Datensätze an, die dem aktuellen Datum entsprechen. Vorherige Datensätze können dann in dem zweiten Formular betrachtet und geändert werden.

Gruß

Robert

Re: Abhängige Listenfelder machen Probleme

Verfasst: Fr, 01.06.2012 23:10
von Ignis Pugnatur
Also ich denke, dass für den allgemeinen Gebrauch und auch meine Zwecke das

ALTER TABLE "Tabellenname" ALTER COLUMN "Datumsfeldname" SET DEFAULT CURRENT_DATE

ausreicht.
Wenn ich das nun richtig verstehe, muss das in SQL rein.
Im Hauptfenster von Base (das erste das beim Start angezeigt wird) auf Extras - SQL
Im sich dort öffnenden Fenster muss das in das obere Feld "Ausführendes Kommando" und anschließend mit "Ausführen" bestätigen.

Das Datum wird dann in Base (also im Formular) nicht angezeigt aber von SQL bei Beendigung des Datensatzes in ALTER TABLE "Tabellenname" ALTER COLUMN "Datumsfeldname" abgelegt und so mit dem Datensatz gespeichert.

Korrigiere mich bitte wenn ich das nun falsch verstanden habe.

Mir würde das ja schon vollkommen reichen.
Wenn ich die Uhrzeit wissen will, dann schaue ich auf die Systemuhr oder die gute alte Analog TickTack an der Wand .. hehe

Re: Abhängige Listenfelder machen Probleme

Verfasst: Sa, 02.06.2012 08:55
von RobertG
Hallo Beni,
Ignis Pugnatur hat geschrieben: Das Datum wird dann in Base (also im Formular) nicht angezeigt aber von SQL bei Beendigung des Datensatzes in ALTER TABLE "Tabellenname" ALTER COLUMN "Datumsfeldname" abgelegt und so mit dem Datensatz gespeichert.
Mit "ALTER TABLE" änderst Du die Tabelleneinstellung. Du setzt einen Standardwert in der Datenbank. Dieser Standardwert wird geschrieben, wenn das Datumsfeld sonst leer bleiben würde. Du legst also das Datum nicht "in ALTER TABLE" ab.
Das Datum wird bei der Eingabe nicht angezeigt, da es das Datum im Moment des Abspeicherns ist. Das Gleiche gilt für Standardeinstellungen z.B. bei einem Timestamp. Da wird dann auch klarer, warum das nicht über die GUI so einfach geht. Schließlich zählt der Moment des Abspeicherns - im Bereich von Nanosekunden.
Wenn Du jetzt alte Datensätze ansiehst steht dort natürlich das entsprechende Datum (bzw. die entsprechende Zeit) in dem Feld.

Gruß

Robert

Re: Abhängige Listenfelder machen Probleme

Verfasst: Sa, 02.06.2012 12:53
von Ignis Pugnatur
Ich denke nicht dass es einem Heimanwender darauf ankommt (und wenn dann sind das sehr seltene Fälle) in welcher Nanosekunde etwas gespeichert wurde und ob der Zeitwert beim öffnen oder speichern des Datensatzes übernommen wird.
Für meine Anwendung ist es z.B. ausreichend wenn man später sieht, wer hat den Datensatz eingegeben und wann (also Datum und Uhrzeit in Minuten).
Natürlich ist es gut zu wissen wie etwas funktioniert und macht dann den Programmaufbau klarer und einige Dinge verständlicher.
In diesem Falle - warum das Datum im Formular nicht "einfach so" angezeigt werden kann.

Was mich gerade etwas ärgert ist, dass ich die Datenliste wegen der Übersicht in Calk erstellt habe und nun gerne in Base hätte.
Von Excel in Access gab es entweder ein importieren-Funktion (Datenbereiche oder ganze Tabellen) oder man konnte einfach eine Werteliste (auch mehrspaltig) in eine Access-Tabelle kopieren.
Diese Funktion vermisse ich oder habe sie zumindest noch nicht gefunden.
Bei kleineren Datenbanken mit wenigen Datensätzen ist die manuelle Eingabe noch recht einfach.
Sollte so was aber in größere Dimensionen gehen kann das ja Tage dauern biss man die Daten drin hat.

Naja - jeder Medaillie hat auch eine Kehrseite .... :) und man kann eben nicht alles haben.

Wenn ich die Daten in Base habe werde ich auch die hochladen. Vieleicht kann irgendwer sowas ja brauchen (Die Einträge der Listenfelder müssen dann eben je nach Fall angepasst / verändert / erweitert oder entfernt werden).
Artikel werden dann ganz bewusst noch nicht drin sein.

Da das ganze ja ein etwas aufwendigeres Haushaltsbuch werden soll, kommen später auch noch Tabellen und Formulare für die Finanzen (Einnahmen, Ausgaben, Fixkosten etc.) dazu.
Ich werde z.B. feste Einnahmen oder Ausgaben auch als "Artikel" mit einer Fiktiven EAN ablegen, die ich über ein externes Tool erzeuge und ausdrucke (auch an den Kassen im Einzelhandel hängen oft Listen mit Codes die die Kassiererin/Kassierer bei bedarf einliest. z.B. Pfand, Gemüse, Obst, Backwaren, die oft frisch angeboten werden, haben dort oft einen Standartcode für mehrere Produkte einer Art und/oder Preisklasse.)
Beispielsweise wären da so Sachen wie: Versicherungen die vierteljährlich gebucht werden, das Zeitschriften-Abo, der Lohn etc.
So muss man auch das nicht jedes mal manuell eingeben sondern hat dann einen Code der gescannt wird. Es müsste dann nur noch der Betrag, Menge etc manuell eingegeben werden.
Aber soweit muss ich auch erst mal kommen.

Ich werde die DB erst mal Testen und dann erweitern.
Ich melde mich dann wieder um Bericht zu erstatten oder euch weiterhin mit Hilfegebettel auf die Nerven gehen.

Hier habe ich mal die Calk-Tabelle mit den Daten für die drei Listenfelder.
K1 - Hauptgruppe | K2 - Gruppe | K3 - Untergruppe

Tabellenblatt 1 - Die Aufgliederung damit man das mal übersichtlich hat
Tabellenblatt 2 - So soll es dann in den 3 Tabellen in Base aus seehen damit die 3 Listenfelder gefüttert werden.

Danke und ein ruhiges Wochenende wünscht euch
Patric

Re: Abhängige Listenfelder machen Probleme

Verfasst: Sa, 02.06.2012 13:49
von Ignis Pugnatur
Ich muss mich korregiern !

Was mich gerade etwas ärgert ist, dass ich die Datenliste wegen der Übersicht in Calk erstellt habe und nun gerne in Base hätte.
Von Excel in Access gab es entweder ein importieren-Funktion (Datenbereiche oder ganze Tabellen) oder man konnte einfach eine Werteliste (auch mehrspaltig) in eine Access-Tabelle kopieren.

Gewusst wie .... Tabellenimport

Vieleicht sollte ich vor dem posten noch etwas länger Googlen :oops:

Und hier auch gleich die rohe DB ...
Dateneingabe habe ich noch nicht versucht .... aber die Listenfelder gehen.
Nach dem Starten öffnet sich ein Hauptmenü mit einer Schaltfläche. Die öffnet das Artikeleingabemenü mit den besagten Listenfeldern.
Merkwürdigerweise muss ich das Fenster erst schliessen und dann nochmals öffnen (über den Button) damit in den Listenfeldern die Einträge gezeigt werden. Ausserdem ist die Ladedauer etwas lang. Zu viele Daten können das wohl noch nicht sein .... Wie lange läd dann eine DB mit mehreren tausend Datensätzen ... *grübel*

LG Ignis