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

Um evtl. Verständnisprobleme zu beheben hab ich mal eben eine Beispiel DB zusammen genagelt, die zeigt, wie Hfo und Ufo miteinander verknüpft werden können.
Gezeigt wird die eine Variante A, mit Verknüpfung über die Eigenschaften 'verknüpfen von und verknüpfen nach' und Variante B Verknüpfung mittels Code.
Erläuterungen sind in der DB als Forms und in Codekommentaren.

Vllt. hilft das ja etwas weiter ?????

 

Ich kann dir nicht folgen (in die Versammlung eh nicht, aber auch hier nicht):

Wie wähle ich denn ist der nächsten Liste nichts aus? Das ist gar nicht vorgesehen!

Auf neuen Datensatz, aber wo?

Ah, jetzt dämmerts. Das frmMake lässt alle ProductDivisions zu, du aber willst "derzeit" nur Trucks anlegen können. Dann wirst du dies dem Formular klarmachen müssen. Da das kein eigentliches Ufo ist, sondern ein völlig autonomes Form, greift hier nicht die automatische Vorbelegung.

Das Mitteilen erfordert Code. Da gibts mehrere Möglichkeiten:

• Übergabe der Typenummer als sog. OpenArg bei Docmd.OpenForm als leztes Argument. Dieses OpenArg kann ein beliebiger Wert sein; er wird einfach durchgeschleust und steht im neugeöffneten Formular über Me.OpenArgs zur Verfügung. Darauf könnte das neugeöffnete Formular dann beim Laden reagieren, indem z.B. das Textfeld für den Type gesperrt wird und einen DefaultValue erhält, den ihm das OpenArg zuflüstert.
• Etwas "schöner", aber codelastiger wird es, wenn du den Type als benutzerdefinierte Property an das Form übergibst und dieses Form dann diese Eigenschaft ausliest, um Defaultvalue und Sperrung zu steuern. Damit ist das ganze etwas besser lesbar, und du kannst auch auf Interaktion im Formular reagieren. So mache ich das auch in der DB, die ich dir neulich in Sachen generische Vertragsdetails als Bild gezeigt habe. Allerdings ist diese Sache halt etwas aufwendiger.

 

Siehe Beitrag Nummer #3

 

\@stuz:
ok, prior art. *Smilie Unser hellenischer Freund hats aber nicht aufgeschnappt, ich selbst auch nicht.

 

So meine Lieben,

sry für die Verspätung, hat a bisserl länger gedauert. Hab auch um 13 Uhr einen Termin und bin (ich hoffe diesmal ist meine Einschätzung besser) um 14.15 ggf etttttwas früher wieder da.


I hob nüx verstanden :-)
Das mit deinem Beispiel DB mit der Synchronisation, schaue ich mir nach dem Termin an. Und jeder Beitrag danach -> nix kapiert :-)

 

\@stuz

habe mir deine DB angeschaut. der Unterschied (den ich mir wünsche) ist, dass ich bei Type nicht selber reinschreiben muss, sondern da sowieso vorher der type "Truck" gesucht wird, dass automatisch Truck auche ignetragen wird. wenn jemand einen anderen Type wie "Bus" als voraussetzung haben will, muss er sowieso vorher in der lst_type auf Bus klicken.

:-)


verständlich rübergebracht?



lg

 

#17 ab "Ah, jetzt dämmerts" gelesen?
Ab wo ausgestiegen?

PS: du schuldest uns keine Rechenschaft, warum und wann du (nicht) hier bist. Wer nicht da ist, ist nicht da. Geholfen wird eh allen, egal ob sie hier lauern oder nicht.

 

habe mir den beitrag #17 noch mal durchgelesen. habs kapiert.
und da kann ich zu sagen, ja ich möchte doch lieber die "zweite" möglichkeit

weil ich damit gewährleiste, dass es einfach korrekt ist :-)
aber ohne eure Unterstützung krieg ich des net hin.

-> Zu meinem Verständnis noch mal:
Type = eine eigenschaft die ausgelesen wird und dem Formular direkt übergeben wird (was ich ziemlich zielorintiert und strukturiert finde) dieses form schaut dann noch mal und sagt, ok dieser wert wird übernommen. das mit defaultvalue und sperrung steuern habe ich nicht verstanden.

naja, wenn der anwender eben auf "Bike" klickt, soll halt in "Make" als voraussetzung "Bike" automatisch eingetragen werden, nicht nur die Bezeichnung, sondern auch im richtigen Feld (type_id_f) soll dann die ID stehen, welche in der tblType das Bike definiert. So gewährleiste ich die korrekte Darstellung (rein theoretisch).

 

Doch hast du. Weil du (!) das hier verlangst:

Der Defaultvalue (zu deutsch STandardwert) sorgt für die automatische Eintragung eines Wertes bei neuen Datensätzen. Und damit diese Vorgabe nicht manuell überschrieben wird, sperrt man das. Wer von Bikes redet, redet also auch im neuen Form von Bikes (Defaultvalue) und kann das nicht ändern (gesperrt).

Ja. Und: Zielorientiertierung und Struktur sind 90% der Programmierung. Das ist also nicht ziemlich cool, sondern einfach notwendig. Voodo und Ganzfestdrandenken hilft i.d.R. nicht.

Erster Schritt:
Baue im Make-Formular folgenden Code neu ein. Achte bei den fett markierten Stellen auf die richtigen namen (ich hab deine nicht mehr im Kopf und bin zu faul, sie aus deiner DB rauszupopeln):
Code:

Die Datenquelle des Forms wird also immer wieder neugeschrieben und kann daher aus dem Entwurf des Forms raus!

Zweiter Schritt:
Im aufrufenden Formular, beim gewünschten Ereignis, wird der Docmd.Openform-Aufruf ersetzt durch:
Code:

Dritter Schritt:
Testen. Danach kommt dann das Reagieren auf Ereignisse.

 

ich komm mit der DB nicht weiter -.-

Ich bin gerade sogar am grübeln, ob das mit dem modell so passt?
Ich kann keine traditionellen kombinationsfelder anlegen, damit der Anwender sich das gewünschte rauspicken kann. Das irritiert mich sehr für den Selektor. Schließlich muss der Anwender doch eine Auswahl bekommen und dann sich entscheiden können, ohne das gleich die ganze Spalte geändert wird. (Bei mir wird die ganze Spalte dann mit dem einen Eintrag gefüllt, logisch, da des ja des "selbe" Feld ist).

ach ja, und des mit dem Code hab ich nicht hingekriegt. wo muss ich den denn einfügen???? *biggrin.gif*

 

Der Code muss ins Formular, das die Makes anzeigt.

Warum? Wo klemmts?

Versteh ich nicht. Wo ist das Problem? Waren wir nicht schon weiter?

 

Jain, theoretisch waren wir weiter, aber praktisch noch nicht :-D
-> ich jedenfalls nicht -.-


Ich hab das jetzt auch noch n bisschen den aktuellen Geschenissen angepasst. Siehe Bildanhang.
Begründung für die Änderung:
Hierarchie: Type -> Make -> Range bleibt. Range ist die Baureihe, daher soll direkt danach das Fahrzeug mit den Komponenten gesucht werden können. Daher habe ich tblObject aus der Hierarchie entfernt (tblObjects hat nur den namen des Fahrzeuge). tblObjects ist nun einfahc an die tblValue gehängt. in der tblObjects wird weiterhin nur der Name stehen. Reicht ja, wenn man das in Verbindung mit der tblvalue bringt. (meine ich)

Nun will ich, ich kenne das Wording nicht, daher sage ich mal "Suchmaske" (bitte korrigiert mich) erstellen.

Ich Habe mich für Truck - Percedes-Renz - Actros:
- Nun möchte ich dass der Anwender direkt in eine Suchmaske die Werte eingeben kann, die das Fahrzeug beschreiben und dann geht es weiter.

Was geht weiter?
- Nun soll deutlich gemacht werden, ob es diese Auswahl, die der Anwender getroffen hat, schon existiert oder nicht. Wenn nicht, soll er das einfach anlegen können. Wenn sie schon existiert, dann soll der Anwender weiter geleitet werden können zu seinem gewünschten output/ was auch immer.


Problem der Kombifelder
Mein Verständnis zu den kombis hackt an Folgendem:
Die Daten werden ja in einem Ufo dargestellt. Diess ufo besteht aus der tblValue:
- value_id
- range_id_f (bezug auf die baureihe)
- pro_id_f (bezug auf die komponenten)
- value_name
- value_remark

Dh. eine "Auswahl" besteht im Endeffekt nur aus einem Attribut. Da das Ufo ein Endlosformular ist, wird dies ja so oft untereinander dargestellt, wie Input vorhanden ist. Wenn ich nun eines von denen als Kombifeld habe und da drin was ändere, wird es ja für alle Einrtäge geändert, obwohl die für mich einen ganz anderen "property" wert darstellen.
Aber ich will ja, dass der Anwender sich zB in der Suchmaske doch aus den vorhandenen Sachen seinen "TrucK" auswählt.

Gehe ich das falsch an? Muss ich anders denken?


EDIT (alt) Anhang vergessen, ist nun dabei.
EDIT (neu) falsche datei ... -.- heute ist nicht mein tag

 

Verstehen wir beide dasselbe unter den Begriffen Fahrzeug und Baureihe?

Hier meine Definition:

Eine Baureihe ist eine vom Hersteller vergebene Bezeichnung für eine Familie/Linie/Gruppe von Fahrzeugen. Eine Baureihe hat bestimmte einheitliche Grundparameter, aber innerhalb einer Baureihe kann es unterschiedliche Varianten geben. So bietet der VW Golf z.B. verschiedene Motorisierungen, Innenausstattungen und Lackfarben, aber es sind alles Golf-Exemplare (Gölfe *Smilie ). Baureihen anderer Hersteller sind z.B. der Corsa von Opel oder der Colt von Mitsubishi.

Ein Fahrzeug ist ein Blechvehikel. An Fahrzeuge kann man Nummernschilder dranschrauben, Treibstoff reinkippen und Beulen reinfahren. Ein Fahrzeug ist etwas Konkretes, nichts Abstraktes. Jedes Fahrzeug gibt es nur einmal. Ein Fahrzeug ist eine in Blech gepresste Ausprägung (!) einer Baureihe; bei der Prägung erhält sie bestimmte Werte in die Eigenschaften, die ihr aus der Kombination von Baureihe und Typ zukommen: Dieser Colt ist rot und hat einen Dieselmotor; dieser Golf ist blau und hat einen Benziner. Beide sind sie Personenwagen und haben infolgedessen weder Liegekabine noch Sattelkupplung.

Was sind da nun die Objects, und was sind die Values?!

 

Diese selbe Definition von Baureihe habe ich auch.

Objects definiere ich wie folgt. Objects sind die genauen Namensbezeichnungen der Fahrzeuge. Daher in der Hierarchie nicht notwendig.

Das gezielte Fahrzeug befindet sich mit Tank usw. doch schließlich in der tblValue. Die Value beschreibt die Kombinationen der einzelnen Baureihen.

 

Was für einen Namen hat ein Fahrzeug? Meine Frau hat ihr ersten Auto Sven genannt, meinst du sowas? *Smilie Der rote Golf ist doch einfach nur ein roter Golf. Was hat der noch für einen Namen?!