Office: (Office 2010) neuer Datensatz in abhängigen Verbindungen

habe das datenmodell kapiert. Danke dir.

Die "Timeline" ist durch die Datensätze für die Modelle auch hinzugefügt.
Also werde ich mich jetzt an die Formulare setzen.


Die benutzeroberfläche soll möglichst "intuitiv" gestaltet werden. So wie du es bisher ja mitgekriegt hast, durch Aktion = Reaktion -> ein Klick aktiviert nächstes Feld usw.
Mein Cheffe soll sich da "durchklicken" ohne mich fragen zu müssen, was er klicken muss. Dann hab ichs geschafft :-D


Ist es daher interessant es so zu gestalten, dass der Anwender sich entscheidet, ob er zwischen "Daten einpflegen" und "Planungstool" (nenn ich mal) sich entscheiden sollte am Anfang. Oder ist es interessanter es nach dem motto zu gestalten: Dort wo informationen benötigt werden, sollte man sie eingeben können?
So wie du das bisher gesehen hast, wie ist deine meinung? Ich fand das eigentlich sehr zielführend.

 

Das hängt davon ab, wie oft sich die Daten ändern. Wenn die verfügbaren Achs- oder Motortypen etc. ständig wechseln (neue rein, alte raus), dann sollte man das on the fly machen können. Wenn aber diese Daten für eine Weile stabil sind, dann würde ich das trennen in Datenpflege und -auswertung.

Man könnte es auch dezent kombinieren: es ist grundsätzlich eine Suche, aber jedes der Suchfelder erlaubt über einen Bearbeiten-Button das Ändern des gesamten (!) Vorrats. Wer also den Typ "Truck" auswählt, kann auch Knopfdruck sehen, dass es neben Truck auch Bus und Bike gibt, und diese Liste editieren. Ist das abgeschlossen, geht die Bearbeitungsliste zu, und die Suche ist mit neuen Werten möglich.

 

Die dezente Kombination gefällt mir ;-)

mein Plan:
Die Hierarchie ist ziemlich stabil (logisch) daher kann man das in die Art und Weise machen, wie ich es bisher hatte. Finde ich "gut so".

Dann sind wir ja beim Model.
Der Anwender sollte jetzt sagen ... ich "suche" ein modell. also liebes Tool, ich wähle jetzt aus drei kombinationsfelder aus nach welchen Kriterien schon mal eine Vorfilterung statt finden soll. Das soll das "modell" sein. Das Modell besteht aus drei informationen "Achsenkonfiguration 4x2"; "Applikation Sattelzug"; "Homologation 18Tonnen Zulassung". (sinnvoll ?? ja/nein)
-> Ich finde es sinnvoll, da dort der Anwender schon mal eingrentzt, was ihm die Suche erleichtert.

Frage:
Diese Auswahl ... das passiert in der tblEingestelltEigenschaftswerte. Richtig? Denn da stehen ja die aktuellen Fahrzeuge drin. Man kann ja nicht nach etwas filtern, was es nicht gibt.
Frage nr.2:
wäre es nich sinnvoll in diesem Moment die möglichket zu gewährleisten, eine neue Kombination hinzuzufügen die nicht vorhanden ist? -> ich würde sagen ja.
Frage nr.3:
kann man nicht einfach als Source die tblEigenschaftswertevorräte nehmen, da dort alles steht, und dann einfach die Kombinationen anzeigen lassen, die in der tblEigenstelltEigenschaftswerte stehen? (sinnvoll? ja/nein?)


Zurück zum Thema
Wenn wir also unser Fahrzeug/ Fahrrad, was auch immer ausgewählt haben, soll es zur zeitlichen planung gehen. In der "Auswahl des Fahrzeuges" sollte vom dem Thema "Zeitplanung" nichts zu sehen sein! (finde ich, aus dem Grund, wie man unterschiedliche Abteilungen trennt, sollte man auch hier trennen). In dieser Zeitplanung konsultiert der Anwender die zeitliche Schiene. Anschließend nächstes Formular, wo ihm des einmal grafisch dargestellt wird. Dann werde ich noch nen schönen Bericht erstellen, damit er das ausdrucken kann. Und der Anwender sollte dann eigentlich recht glücklich sein ^^

... ich hoffe es für ihn :-D



Wie siehst du das? ist der "rote Faden" vorhanden? was würdest du am Plan ändern?

 

ad Frage 1)
Wenn das Suchergebnis nur eine Liste von Modellen sein kann, dann stimmt das so.

ad Frage 2)
Die Anlage eines neuen Modells erfordert aber die Angabe von Typ, Hersteller und Baureihe.

ad Frage 3)
du könntest das machen. Du könntest dann die Eingestellten Werte, die überhaupt in irgendeinem Modell vorkommen, zusammenstellen ("Nachbrenner, V8-Motor und Pendelachse"), und die Suche ermittelt dann die Modelle, die diese Eigenschaften vereinen. Allerdings werden dann Werte, die bei keinem Modell vorkommen, nicht angeboten. Wenn also kein Modell einen Nachbrenner hat, obwohl es "grundsätzlich" sowas geben kann, dann wird der Nachbrenner gar nicht angeboten. Wenn du statt auf die eingestellten auf die möglichen Werte (=Vorrat) gehst, kann man frei suchen und auch den Nachbrenner checken: "könnte sein, gibts aber nicht. Bauen wir ihn!".

Zur Trennung zeitliche/technische Eigenschaften:
Du könntest die Eigenschaften kategorisieren. Füge eine neue Spalte dazu, die festhält, ob die Eigenschaft eine technische, zeitliche oder sonstige Kategorie ist. Nach diesen Kategorien könnten deine Suchmasken dann filtern, welche Eigenschaften zur Wahl zu stehen haben.

 

AW: ad Frage 1
ich würde das erstmal als eine Liste aufsetzen. schauen wa mal ob das ankommt.

AW: ad Frage 2
Type, Hersteller und Range sind doch schon vorher ausgewählt? :-)
Da kommt des wieder ins Spiel von neulich. Ich würde einen neuen Truck hinzufügen wollen, aber da ich mich doch schon für Car-PercedesRenz-SLK entschieden haben, ist ja klar, dass das neue Fahrzeug auch ein SLK sein muss.

AW: ad Frage 3
das hab ich doch gemeint :-)
deine tblEigenschaftsvorräte = meine tblPropStock (da stehen alle möglichen Werte drin)
deine tblEingestelleEigenschaftsvorräte = meine tblValue (die aktuellen beinhaltenden Kombinationen)
->> gut, im Fazit sind wir ja einer Meinung. die tblEigenschaftsvorräte aka tblPropStock wird es.


Habe eine neue tbl angelegt. sie nennt sich tblData. Dort gibt es für jede "möglichkeit" einen datensatz. technical information 1, chronologial information 2 usw.
der PK befindet sich in der tblEigenschaftsvorräte als FK. das passt. da kann der Anwender dann wieder über Kombifeld auswählen welche art von Information es sein soll.


Wie pflege ich meine tblEigenschaftsvorräte & meine tblEigenschaft ?
Ich habe ja in meinem Planda von nichts erwähnt habe ich bemerkt :-)

 

tblData ist ein unschöner Name. Daten ist alles. Das sind Eigenschaftskategorien!

Wenn das so ist, dann mach das so.

Mit ein paar Formularen?!

 

Und wo wäre es logisch? da zB die Hierarchie direkt bei der lst auf -> New neue hinzugefügt werden können. bei den Fahrzeugen, will ich das Model wie eben gesagt mit bezug auf hierarchie erstellen. und dann kommt der anwennder ja rein theoretisch zu seinem output.

diese zwei tbl's sind aber Daten, welche nicht durch vorherige auswahl eingefügt werden soll/ können/ werden. damit sie anschließend für die benötigte Wahl zur Auswahl stehen.

-> also könnte/ sollte ich für diese tbl's am anfang unterscheiden zwscieh daten einpflegen (da kann man dann nur diese hinzufügen). und der rest bleibt wie es ist. und damit der anwender das auch kapiert, erstelle ich einige Textfelder mit Informationen, damit er weiß was wo ist.
jain?

 

Die Eigenschaften und ihre Vorräte haben an sich nichts mit den Typen, Baureihen und Modellen zu tun. Die Eigenschaften und ihre Vorräte sind eine Art Verzeichnis der überhaupt in Rede stehenden Einstellgrößen. Hier erfährt Access, dass es überhaupt ("Irgendwo") von Nachbrennern, Werkradios und 4-Zylinder-Reihendieseln reden soll.

Wenn ab nächstem Jahr alle PKW z.B. eine neue Eigenschaft "Recyclingfähigkeit" liefern müssen, dann ist das ein neuer Eintrag in den Eigenschaften. Für den Typ PKW wird diese Eigenschaft ins Pflichtenheft übernommen, d.h. jeder PKW muss sich ab jetzt dazu äußern. Über Inkonsistenzabfragen kannst du dann feststellen, welche Modelle diese Eigenschaft noch nicht im Pflichtenheft haben (=alle PKW). Die neue Pflicht kannst du dann ins Pflichtenheft anfügen lassen und in den Eingestellten Werten nachtragen.

Es ist dir überlassen, zu beurteilen, wie oft solche Eigenschaften sich ändern und wo damit eine Änderungsmaske eher hinpasst.

In meinen Anwendungen (die allerdings nicht aus der Produktionswirtschaft kommen) ändern sich die Wertevorräte eher langsam. Daher habe ich mir angewöhnt, die Wertevorräte in einem völlig separaten Teil zu bearbeiten. Wenn also morgen eine neue Währung ins Spiel kommt oder eine neue Kontoart, dann trage ich die nicht mal so eben "ad hoc" in einem Kombifeld nach, sondern pflege das in einer eigene Wertevorratsverwaltung. Ich "ziehe das vor die Klammer". Aber wenn es bei dir volatiler ist, bau es halt näher an die Nutzung der Daten.

Deinen bisherigen Ansatz mit einer mehrstufigen Kombination aus Listenfeldern finde ich ganz gut, allerdings ist die Pflege der Listfeld-Einträge über die New/Edit/Delete-Buttons für mich etwas unorthodox. Ich würde die Wartung der Listeinträge eher durch ein je Liste separates Pflegeformular regeln: eines für Typen, eines für Modelle, eines für Baureihen etc.

 

Ich habe mich entschieden, die Eigenschaften und Vorräte unabhängig einzupflegen. Gleich am Anfang hat man sich zu entscheiden, was man in dr DB machen will.

Bzgl der Hierarchiepflege. Das werde ich über seperates Formular machen, das ist angenehmer.


Ich habe nun ein problem mit den Kombinationsfeldern. Könntest du dir das frm_Structure_under anschauen? Es ist ein Endlosformular. Es ist im frm_Structure als Ufo.
Nach der Hierarchieauswahl, muss man ein Model wählen. Dann ist rechts danaben das Ufo (Structure_under). Hier soll nun durch die Kombinationsfelder ermöglicht werden, seine Ausahl zu selektieren. Jedoch klappt das noch nicht so ganz mit dem cbo feldern, wie ich das gerne hätte.

Was habe ich falsch gemacht im "frm_Structure_under"?


EDIT: wie grenze ich die Kombinationsfelder auf die dazu gehörigen Properties ein?

 

Was hättest du denn gern, und was funktioniert nicht? Details bitte! Und ein Beispiel!

Edit: ah, ich vermute ich habs.
Die Kombis zeigen in allen Eigenschaften noch alle Vorratswerte an. Du willst bestimmt, dass die Eigenschaft Achsen nur die Achsen anbietet, keine Motoren. Das ließe sich machen. Die Datenquelle des Kombis muss auf den aktuellen PropID-Wert gefiltert werden.
Code:

 

Die Kombis sollen auf die Eigenschaften eingegrentzt die "Optionen" anzeigen, haste richtig verstanden :-)

Ich habe deinen Code eingefügt, aber funktioniert nicht :-(
Wenn mein "stock_name" ein TxtFeld ist, kriege ich folgende Fehlermeldung (logisch): Laufzeitfehler "438". Objekt unterstützt Diese Eigenschaft der Methode nicht.
Wenn stock_name ein Kombifeld ist, kommt die Fehlermeldung nicht, aber dennoch stehen alle Optionen untereinander. (als wäre nichts passiert)


EDIT:
funktioniert !!! Dennoch bleibt ein Problem über. In den Kombinationsfeldern hab ich die gefilterte Auswahl, aber links stehen immernoch "alle" Propoerties mehrfach aufgezählt, der Anzahl betreffend der PropStock -.-

 

Das Kursive verstehe ich nicht... Wo du wolle? *Smilie

 

haha, warum das kursiv geworden ist, weiß ich auch nicht :-D

also damit meine ich folgendes:
siehe bild

in den Kombifeldern holen die sich die Info der Prop-ID und zeigen mir auch die richtige Auswahl an. Aber links steht zB. vier mal untereinander "ApplicatioN" weil es 4 Einträge zu Application gibt. Das soll aber gruppiert sein. Es soll nur einmal da stehen.

Dieses Formular wird meine "Suchmaske". Hier soll der Anwender nach Auswahl seines Models in die Suche gehen. Er sucht sich nach den bestehenden Informationen seinen Wunsch aus. Anschließend soll dann in der tblValue gesucht werden, ob es den zB schon gibt. Wenn nicht, dann anlegen zB. wenn ja, soll mit dem bestehenden ausgewählten Fahrzeug weiter gearbeitet werden.
-> Frage:
ich habe mir das Datenmodel noch mal angeschaut. Eine Frage hat sich mir eben erschlossen. In der tblValue (deine tblEingestellteEigenschaftswerte) ergibt sich eine Value_ID aus dem Model und den Properties.Damit wird uns gesagt, welches Model, welche Eigenschaften hat. Aber wo steht, wie der Truck genau konfiguriert ist? Welche genau Achse er hat, welche genaue Reifen er hat?

Die Infos kommen zwar aus der tblPropStock, aber werden aktuell nirgend abgespeichert?! Oder kommt da das Pflichtenheft ins Spiel?

EDIT: bild vergessen -.-

 

Das ist ja auch das Unterformular. Das ist nicht zum separaten Einsatz gedacht, da es sich ja eben auf das aktuelle Modell synct. Und im aktuellen Modell gibts jede Eigenschaft nur einmal.

Ebenfalls in den EingestelltenEigenschaften. Da steht drin: Modell X hat in Eigenschaft Y den Wert Z.

 

ok, verstanden.
Und wie kann ich mein gewünschstes Ziel sonst erreichen?
Ich will ja, dass der Anwender aus den bestehenden Vorräten, seine aussucht, dem ensprechend in der tblValue nach seinem Wunsch gesucht wird.

Wenn das Ufo nicht zum seperaten Einsatz gedacht ist, ... irnwie muss das ja gehen?!


Aber die tblValue hat keinen "f_stock_ID".
Kann ich daraus also entnehmen, dass ein TEXTfeld in der tblValue mir den Wert Z darstellt? Das fände ich ja eigentlich sogar ziemlich gescheit :-)

Und was die "Pflege" angeht, kann man daraus doch bestimmt wieder n cboFeld machen, um zu PropStock für jedes Fahrzeug zu pflegen?


:-)