Office: (Office 2010) Formular Textfelder aktualisieren nicht

Schauen wir mal, ob ich es verstanden habe (ich glaube ich habs net kapiert)
So sieht das Model nun aus. Des rote erkläre ich gleich.

Wenn wir das so wie es jetzt ist betrachten, wird doch gesagt, dass jedes Objekt (also die Fahrzeugbezeichnung -> das Fahrzeug) eine Ebene tiefer gehen und dort das Fahrzeug genau abgebildet wird, ... welche Optionen, Radstände usw. usw.
Wenn wir also in der tblValue alle möglichen Optionen stehen haben, kann ich über den Selector sagen, dass er die daten aus Value holt und sie in ObjectStock speichert. So kann ich die Autos darstellen. ?!?!?!????
Wenn nun im genau diesen Fahrzeug eine Option geändert wird, bleibt das Fahrzeug im Endeffekt gleich, es ändert sich zB nur der Reifen von 190/40 R17 auf 190/40 R15, der Rest würde doch erhalten bleiben?

Wenn der Anwender sagt, es gibt jetzt noch einen vierten Reifen "200/45 R09" dann wird der einfach der Properties "Reifen/ Tires" zugewiesen und wird in der tblValue einfach als zusätzlicher Reifen eingetragen.
Frage: Es müsste doch aber vorher wieder durch die Struktur Type,Make,Range, Object gehen, damit klar ist, wo der Reifen steht???


Nun zu meinen roten Markierungen. tblObject und tblValue trennen. tblObject mit tblObjectStock verbinden und von dort aus auf tblValue und auf tblProperties. -> sinnlos?!!! oder? das ergäbe doch keinen Sinn?, weil doch dann doch wirklich jedes fahrzeug mit jeder option angelegt werden würde -> richtig?
Wollte nur eine fachliche Meinung zu diesem Gedanken, -> zu was das führen würde, wenn ich es so machen würde.


Und noch mal ein Danke bisher, dass du so geduldig mit mir bist ;-)

 

Object und Value müssen verbunden bleiben.
Und Die ObjectStocks (= Objekt-Vorräte) sollten eher Property-Stocks sein. Da werden ja später nicht vorrätige Objekte drinstehen, sondern vorrätige "Standardwerte" für Properties.

Denke wir das mal für einen Truck durch:

• Type = Truck. Damit steht schon fest, welche Eigenschaften später Truckfahrzeuge haben müssen: Liegekabine, Achsanzahl, Motorart etc.
• Make und Range beschreiben das Fahrzeug lediglich genauer (Hersteller, Modellreihe).
• Object ist nun ein echtes Fahrzeug: etwas, wo ich eine Beule reintreten kann (das wird dir bei der abstrakten Actos-Linie von Perpedes eher schwer fallen).
• Das Object muss aber, da es ein Truck ist, bestimmte Truck-spezifische Eigenschaften "ausfüllen". Der Type Truck verlangt z.B. Achsanzahl, Motorart, Liegenkabine etc. Diese "type-abhängigen Pflichtangaben" werden jetzt für das Object erfragt: Liegekabine = ja, Achsanzahl = 3, Motorart = V8 Diesel. Ein anderes Truckobject kommt vielleicht ohne Liegekabine, mit zwei Achsen und 4er-Reihendiesel.
• Eigentlich müssten die Eigenschaften alle händisch ausgefüllt werden. Es gibt aber "beliebte" Werte für manche Eigenschaften. Für Reifen kann man z.B. nicht jeden Werte angeben, sondern nur eine der nutzbaren Reifengrößen. Die müssen irgendwo liegen. Auch die Motorarten werden wohl nicht unendlich viele sein (sonst sind es keine Arten). Diese Werte stehen als mögliche Propertywerte zur Verfügung.
• Die nutzbaren Reifen sind überall dieselben. Egal ob Trecker oder Fahrwerk einer 747: wo Reifen dransteht, muss es einer dieser Reifen sein: (Liste aufklapp). Für Typbezeichnungen und ähnliche "Nachnamen" git es hingegen keinen Vorrat.

 

kapiert.

Es hat sich noch eine Frage gerade ergeben. Was mache ich mit abhängigen Werten? Zum Beispiel haben wir unterschiedliche
- Hinterachsen. Jede Hinterachsen hat ein bis zwei Hinterachsübersetzungen.
- Radstände. Jede Achsenkonfiguration hat vorgegebene Radstände
- EURO Normen. Jeder Motor ist abhängig, ob er zB Typ 3, oder 4, usw. ist

Müsste ich da noch eine Tabelle teifer gehen und sagen. Properties ist allgemein gehalten, propertiesstock gibt mir die genauen details und noch tiefer sehe ich die abhängigkeiten?? oder -> kann ich einfach die zB Hinterachsübersetzungen ebenfalls in die propertiesstock reinhauen. sind im endeffekt ja auch nur genaue Werte wie die vorheringen nur, nur mit abhängigkeiten. schließlich wird der Truck sowieso in der Value gespeichert, und dort kann ja wiederum die Hinterachsübersetzungen als normaler Datensatz stehen, da er der einzige sein wird ?!?!

 

Versteh ich nicht. Wenn ein Truck Achsen braucht, und es gibt folgende Achsen gemäß Vorratstabelle (A1, A2, A3), dann ist das doch mit abgedeckt?!

 

Ja, die Vorderachsen schon. Das ist korrekt.

Ein Truck hat eine Achsenkonfiguraiton = 4x2, 6x2, 6x4 oder 8x4 (8Räder, davon 4 angetrieben = 4 Achsen). Die Achsen sind selbstverständlich über die "Vorderachsne" abgedeckt in der Vorratstabelle, genau wie die Hinterachsen. Aber die Hinterachsen sind hahaha "hinten". Vom Motor bis nach "hinten" zu den Achsen ist leider nicht immer direkte Übertragung.

Das bedeutet, eine Motorumdrehung (Drehmoment) ist nicht gleich, dass die Hinterachse auch eine komplette Runde schafft. Also hat man "Übersetzungen" zB hat meine Hinterachse "XY" im produktportfolio das Angebot von zwei unterschiedlichen Hinterachsübersetzungen.
-> will ich die Achse "XY" mit einer 3,07 oder einer 3,8 Übersetzung. Das kann man sich aussuchen. ->>> Ein Drehmoment hat also bei 3,07 die Auswirkung, dass meine Hinterachse sich 3,07 mal um die eigene Achse dreht -> also 3,07 Runden schafft.


Daher weiß ich nicht, ib mein Gedanke bzgl. der Abbilung in der selben Tabelle korrekt wäre?! Oder muss ich echt noch einmal tiefer gehen??


EDIT:idee! -> die Hinterachsen kriegen im Feld "remark" gleich eine Übersetzung zugewiesen, so wählt man sich dann seine Achse aus.
was hälst du davon? Genau so kann man das dann auch für EURO Norm abbilden. Man wählt eine Euro Norm. und dem entsprechend einen Motor.

 

Gegenfrage: was haben die denn dann noch gemeinsam?

Es ist letztlich eine Philosophiefrage: was ist ein "Artikel"? Ist die grüne Variante einer Jacke der gleiche Artikel wie die rote (wenn ja: wie unterscheiden die sich denn dann noch), oder sind das zwei Artikel (wenn ja: was haben die dann noch gemeinsam)? Beiderlei Ansätze sind denkbar. Du musst nur mit den Folgen leben.

Klingt wie: "Stellen Sie sich bitte eine Glaskugel vor. Sie muss aber nicht aus Glas sein, und sie muss auch nicht kugelförmig sein. Haben Sie?" *Smilie

"Richtig" ist das Datenmodell dann, wenn es alles zulässt, was in Wirklichkeit auftreten kann und alles verhindert, was nicht vorkommen kann. Von den richtigen Modellen ist das gute dasjenige, das die wenigsten Redundanzen, Restriktionen und Fallstricke hat.

Solche "irrelationalen" Datenbanken wie deine hier haben eh ihre Tücken, z.B. was das Verhindern von ungültigen Werten angeht ("Gewicht: Fritz" -> darf nicht sein) oder das Zurechttypisieren der Textwerte (alle Values sind Text, aber mit Text ist schlecht rechnen).

 

Es ist genau das SELBE Produkt nur mit einer anderen Übersetzung. Es gibt mehrere gleiche Angebote für utnerschiedliche Zusammensetzungen, aber die Achse ist wie gesagt die SELBE :-)
Es sind 4 unterschiedliche Achsen für "hinten". Die Achse "XY" hat eine Übersetzung von 3,07 + 3,08. Die Achse "AB" hat die Übersetzung von 5,7 + 4,22 (alles nur Beispiele) aber genau so schaut des aus.

Das sollte das ja erleichtern. Genau wie bei den Motoren. Es stehen 4 Motoren zur Auswahl, 2 davon sind Euro 3, zwei davon sind Euro 4.


Über

mach ich mir heute noch mal meine Gedanken. Aber des schaut (dank deiner Unterstützung) schon mal top aus, bisher. Aber wie gesagt, ich werde noch mal alles ganz genau überdenken.

 

Dann mach dir doch mal gedanken, was eine Achse noch ausmacht außer der Übersetzung. Mit hinreichender Energie ist eine 40-Tonner-Hinterachse genau dasselbe wie eine Besenstielachse in der Seifenkiste, nur schwerer, stabiler und teurer... meinst du das Ernst? *grins

Und ein E4-Motor ist immer noch dreckiger als der Gummimotor, mit dem ich vor 30 Jahren meine Balsholz-Flugmodelle durch die Gegend schnurbseln ließ....

 

Es geht ja auch nicht in den Deutschen/ Europäischen Markt ;-)
Ich muss ganz ehrlich sagen ich finde das sch****, aber das liegt wohl daran, dass wir jungen Leut noch zu naiv sind :-D

Die Achse kann eine Außenplanetenachse oder eine Hybridachse sein. Also ein unterschiedlicher "Typ". Wer die "AB" Achse bestellt, kann eigentlich nicht mehr zwischen unterschiedlichen Tonnagen auswählen, sondern nur bei der Übersetzung. Wenn er eine andere Tonnage will, wählt er eine andere (so ist es aktuell).

Jetzt hab ich mir ja auch Gedanken darüber gemacht, was wäre wenn. Wenn die nun die gleiche Achse anbieten, mit unterschiedlichen Tonnagen und sowohl als Außenplanet- und Hybridachse -> das geht nicht (Tonnagen ja, aber nicht unterschiedlicher Typ), weil das Produkt "Achse" ist eine zB Außenplanetachse. Du sagst ja auch nicht bei Percedes-Renz, dass du dir eine F-Klasse bestellst, aber gerne eine G-Klasse bekommst.
Was ist aber, wenn eine andere Tonnage sein soll? Aktuell gibt es nur zwei Tonnagen -> und das sind zwei unterschiedliche Achsen und ich denke, dass das auch so bleiben wird, frage aber nach.

 

Gibt es vielleicht bei den (nennen wir es mal) Ausstattungen eine ähnliche Hierarchie wie bei Type/Make/Range?

Dem Type (bisher Truck/Bus/Bike) entspräche dann z.B. der "Equipment Type" Achse, Motor, Auflieger/Anhängerkupplungsart, etc.

Der Make (Hersteller) entspräche beim Equipment... tja, weiß nicht. Gibts den? Vielleicht auch ein Hersteller?

Der Range (Linie, Reihe) wäre wohl dann deine "Achsvariante": die 3,8 oder die 3,07er-Achse sind vom Eq-Type Achse, der V8 und der 4er-Reihendiesel sind vom Typ Motor etc.

Die Objects gibts dann in dieser Schiene nicht. Objects sind Fahrzeuge. Die Eq-Types können als Fahrzeug-Properties eingesetzt werden. Die Achse ist dann kein Textwert "3,8er Achse" mehr, sondern ein Bezug auf das Achse-Equipment "3,8".

Habt ihr eigentlich keine Informatiker im Haus? *mrcool

 

Dazu enthalte ich mich bescheidener Weise :-D

Jain. Man könnte, hat aber nicht. Ich persönlich finde, dass es sehr sinnvoll wäre, aber ich bin ja nur ein Praktikant, die haben ja nichts zu sagen ^^
Es wird beim Truck unterschied in:
- basic model (Applikation also zwischen Sattelzug oder Chassis, Homologationsgewicht also nach welchen Tonnagen und Achsenkonfiguration wie 4x2, usw.)
Wenn man diese drei Daten kennt, weiß man schon aaa, ok es handelt sich also um einen 4x2 Truck Tractor (Sattelzug) für 18Tonnen.

- nach dem basic model könnte man auf das basic vehicle brechen:
(Motor, Radstand (abhängig von Achsenkonfiguration), Kabine, Frame (Rahmen), Federung und Steuerung (links oder rechtslenker)

- nach dem basic vehicle kann man auf das Standard Equipment brechen:
Getriebe, Hinterachse, Tank, Bremsen, Hinterachsenübersetzung, Kabinenfarbe


Im Basic Model hat man KEINE Optionen. Wenn man anstatt Sattelzug einen Chassis will, ist es ein anderes Produkt. Beim basic vehicle hat man Optionen, jedoch ist es kein anderes produkt, sondern ein anderer "Typ". Und beim Standard Equipment, naja, erklärt sich von selbst, das hat irnwo jeder und man kann alles optionalisieren.

Warum ich da bisher keine Einschränkung gemacht habe?
Weil das Fahrzeug sowieso durch eine Fahrzeugkommision muss. Die setzt sich aus der Projektleitung, Qualitätsauditor, Produktmanagement und noch nen paar Leuten zusammen. Das Tool ist nicht für jemanden "der sich nicht mit der Materie" beschäftigt. Wenn zB eine Selektion vorgenommen wurde, wird das Output der Kommision vorgelegt, die sagen dann: Hey, so steht das nicht im produktportfolio, ändern/ nicht genehmigt. Derjenige, der dort was reinhaut, weiß worum es geht.

Wenn derjenige nun vom 4x2 Truck Tracor 18 Tonnen, usw. etc. den bauphasenplan einsehen will, wird er im Selector die erforderlichen informationen auswählen und gelangt zum Plan. -> Andere Selektion -> anderer Bauphasenplan.


Wenn ich das nun aber für die Trucksparte so eingrenze, ist das Tool nicht mehr flexibel genug für zum beispiel Bus oder Bike, wenn es dort diese Struktur nicht gibt! Die Freiheit soll ich lassen, da wie gesagt, sowieso das Fahrzeug zuerst durch eine Komission muss (so wurde es mir begründet).

 

Ist die Hierarchie also nicht immer 3stufig? Dann könnte vielleicht eine Parent-Child-Hierarchie hilfreich sein, die sich z.B. in einem Treeview zeigen könnte.

So eine Hierarchie kann auch "ragged" sein, also unausgewogen, mit unterschiedlichen "Pfadtiefen". Am Ende eines Pfades, wo bei Windows Dateien stünden, wären bei dir dann die Objects.

Möglicherweise könnte ein zweiter Treeview die verfügbaren Eigenschaften oder "Eigenschaftsgruppen" herbeirouten. Und in den "Dateien" kommen dann beide Welten zusammen.

 

Die Hierarchie Type/ Make/ Range ist schon korrekt so. Die ist auch immer dreistufig.

Andere Sache ... Ich weiß nicht wie ich das "Selector" formular machen soll.
Dieses Formular sagt aus, wie das Produkt aussieht, was gesucht wird.
Also muss der ja auf Range zugreifen, damit er weiß, welches Object gemeint ist. blablabla -> Range, Object, Value, Property und PropertyStock muss in die Datensatzherkunft? Ein "object" ist ja im Endeffekt die Tabelle in der das Fahrzeug lediglich mit seinem "Namen" drin steht. Die eigentliche Zusammensetzung ist im Value. value zieht aus property und property aus propertystock. richtig?

die propertystock muss ich als kombinationsfeld darstellen, damit er mir die Inhalte der tbl anzeigt, damit ich auswählen kann. die werden dann in value gespeichert??? aber wenn ich protpery_name darstelle, stehen ja mehrere Einträge untereinander. des soll ja net sein. wenn ich ein freies Textfeld zur bezeichnung nehme, sieht es toll aus, aber ist es dann nicht eingeschränkt?? ich bin total durcheinander, weiß nicht wie ich das machen soll -.-


Ich hab dir noch mal die aktuelle Version angehängt. kannst du helles ins dunkel bringen? welchen gedanken hab ich nicht kapiert??

 

Kommt drauf an, wie du das Object darstellen willst. Das (eine) anzuzeigende Object ist nur ein Datensatz. Aber außer dem Namen und den übergordneten Hierarchiebenen (Range,Make,Type) "hat" das Object keine skalaren ("tippbaren") Werte. Seine Eigenschaften sind nunmal Vektoren oder Tupel, also "Stapel" von Werten, nicht "Einzelwerte". Diese Wertestapel könntest du z.B. in einem Unterformular zeigen, in einem Treeview oder sonstwie.

Wenn du alles in einer einzigen Datenquelle zusammenlötest, zeigst du nicht mehr das (eine) Object, sondern seine "Atome", d.h. seine vielen Eigenschaften. Das Object zerfließt dabei in den Einzelteilen. Es ist ein Wald, aber er besteht aus vielen Bäumen.

Was willst du sehen? Mal doch mal eine Skizze, wie das aussehen soll.

 

Mir ist nicht klar, wie ich nun gewährleisten kann, dass der Anwender sich im Selektor/Konfigurator durchklicken kann.

Eigentlich würde ich ja im traditionellen Datenbankmodell jetzt aus jeder Trägertabelle ein Kombinationsfeld erstellen, welches die ID und den Namen beinhaltet, Namen anzeigen lassen und in der zusammengeführten Hauptträgertabelle die Werte einfließen lassen, sodass ein "Truck" im Konfigurator aus den vorgegebenen Werten einen Truck erstellt werden kann.
Im Selektor würde derjenige in der Auswahl die vorgegebenen Werte in der Hauptträgertabelle eintippen und ihn zum Output führen.

Hier ist das jetzt anders?!
Hier muss ich dafür sorgen, dass der Anwender im Endeffekt "oberflächlich" aus der Sicht des Anwenders genau das Gleiche macht. Jedoch passiert im Hintergrund was gänzlich anderes. Und ich weiß nicht genau, wie ich das, was passiert, so darstellen soll/ kann, damit es ordnungsgemäß "funktioniert".

Ich muss ja irgendwie über eine Eingabe des Anwenders dafür sorgen, dass der Truck im Konfigurator angelegt werden kann. aber wie? natürlich wird ein unterformular erstellt in dem er arbeitet, des is aber nur benutzeroberfläche, mir geht es gerade den Gedanken zu verstehen, wie ich aber die Funktionalität aufsetzen soll.

- Konfigurator:
Ich muss Werte darstellen, die der Anwender vorher eingetippt haben muss, damit es die Werte gibt, damit er wiederum etwas "zusammenstellen" kann. Er muss auswählen dürfen, welche Komponenten das Fahrzeug hat. Wie gewährleiste ich, dass er nun gezielt die Achse XY auswählen kann? => ich muss im Unterformular bezug auf die unterschiedlichen Tabellen nehmen und mehrere Kombinationsfelder von PropertyStock erstellen, in denen die Einträge zu sehen sind, damit der Anwender ja schon mal auswählen kann. Diese Felder sind gefiltert nach Property. Also wird da auch wirklich nur der Stock der ausgewählten property stehen. soweit so gut. aber wenn es jetzt wieder ums speichern usw. geht, schaltet mein hirn wieder ab -.-

- Selektor:
Bin ich mir noch nicht sicher, ob es eine einfach Suchmaske werden soll, sodass der Anwender ihm bekannte Werte eingibt und als Output alles ernscheint, was den kriterien entspricht, er sich dann sein Ziel aussucht und dann weiter arbeitet
oder (was zielführender ist, weil wie schon gesagt kein unwissender dran arbeitet)
ob ich es so anlegen soll, dass der Anwender den Selector vollkommen ausfüllt (der truck wird doch hier aus der value gezogen??) und dem entsprechend arbeiten kann.