PDA

Vollständige Version anzeigen : neuer Datensatz in abhängigen Verbindungen


dergrieche
05.06.2012, 14:02
Hallo,

ich habe eine tblType:
- type_ID
- type_name

und eine tblMake:
- make_ID
- type_id_f
- make_name


Nun habe ich ein Unterformular, in dem ich in die tblType einfach neue Datensätze reinhauen kann, problemlos, logisch.

Dann soll in einem anderen Unterformular nun bei tblMake was hinzugefügt werden können -> dieses Unterformular kann man nur öffnen, wenn man vorher einen bestimmten "type" ausgewählt hat, und das Formular wird auch dem entsprechend erfolgreich gefiltert. Dort sehen wir nur die einträge, die in beziehung mit tblType stehen. Wie kann ich nun dafür sorgen, dass dort immer automatisch die type_id eingetragen wird, welche schon ausgewählt ist? Der Anwender kommt auf des Formular, trägt nur einen neuen make_name ein und automatisch soll der vorher schon ausgewählte type_id dazu eingetragen werden.


Bitte um Hilfe :-)

Storch
05.06.2012, 14:31
Da eine Beziehung aus Primär -und Fremdschlüssel besteht, muss das UFo ein feld haben, welches den Fremdschlüssel enthält. Dort kannst Du dann den DefaultValue(Standardwert) mit der Type-ID belegen:

Me!Fremdschlüssel.DefaultValue = Primärschlüssel

Als Verweis auf den Primärschlüssel ginge zb:

Me.Parent!Primärschlüssel

Konkret:
Me!type_id_f.DefaultValue = Me.Parent!type_id

stuz1
05.06.2012, 14:32
Wenn das UForm mit den Hauptformular über die Felder

type_ID => type_id_f

verknüpft ist macht die Datenbank das von alleine!

Wenn du das 2te Formular als einzelnes Hauptformular öffnest hat es ja keinen Bezug zu einem Stammdatensatz, oder? Du könntest dann höchstens die tpye_ID in den openArgs mitgeben oder in eine Globale Variable schreiben oder von Formular1 auf Formular2 zugreifen...

So ganz habe ich nicht verstanden was da passiert?

dergrieche
05.06.2012, 14:48
type => type_id_f

@stuz1
die macht das nicht von alleine. bekomme eine meldung, dass das schlüsselfeld nicht ausgefüllt ist und kann nicht speichern (wenn da nichts steht) -> aber ist das nicht verständlich? ich muss doch dem Formular erst sagen, wenn ein neuer Datensatz erstellt wird, dass dort der wert eignetragen werden muss, weiß der doch net von allein? woher? Bitte korrigieren, wenn ich falsch liege :-)


@storch
was ist das ausführende ereignis? -> hinzufügen eines neuen datensatzes, richtig? dh. ich darf den nicht als Schaltfläche machen, sondern muss ihn im VBA erstellen, sonst kann ich ja deinen Code nicht einfügen?? *grins* wie lautet der Code um einen neuen Datensatz anzufügen? *grins* :-D

stuz1
05.06.2012, 15:34
Warum sollte es nicht gehen? Siehe Beispieldatenbank....

(Nur schnell zusammengeklebt, keine Namenskonvention oder so etwas beachtet usw. verwendet....)

Gruß

Stefan

(Edit: Vielleicht baust du ja in diese Demo dein Vorhaben ein und stellst es wieder Online damit wir sehen was du vorhast)

dergrieche
05.06.2012, 15:49
So,

hab des von dir auf meinem Rechner. hier mal meine DB, mit den wesentlichen Inhalten.

Bin jetzt aber ab 17 uhr im feierabend, hab noch Sport ;-)


kurze zusammenfassung:
- typ ist voraussetzung
- make abhängig von typ
- range abhängig von make
- object abhängig von range

Objekt ist der Fahrzeugname. Entweder gibt es ihn, oder nicht. wenn nicht muss auch ehr hinzugefügt werden. Formulare sind logsich aufgebaut, müsste nicht schwer sein, des auf anhieb zu verstehen.


Merci :-)
Fragen dies bzgl beantworte ich ab 20 uhr.


mfg dergrieche

Storch
05.06.2012, 20:49
So,
hier mal meine DB, mit den wesentlichen Inhalten.


Wo ist denn HIER ???

Und so richtig verstehe ich Deine Problematik nicht. Wenn DU verknüpfte Tabellen hast, ein HFo auf Basis der Haupttabelle erstellst, dann ein Ufo auf Basis einer verknüpften Tabelle und dieses UFo dann in das HFo einfügst, dann sorgt Access IMHO automatisch dafür, das die Ufo-Daten bei DS-Wechsel im HFo nachfolgen.

Wenn dem nicht so ist, solltest DU mal die Eigenschaften des UFo-Controls öffnen, Dort gibt es (ich glaube auf dem 2. Reiter, die Möglichkeit, die Formulare miteinander zu verknüpfen. Danach sollte das Fremdschlüsselfeld automatisch die ID der übergeordneten Tabelle enthalten.

dergrieche
06.06.2012, 07:49
vergessen anzuhängen -.-
ich merk schon ... das wird heute n super tag -.-

hier die DB, die ich gestern vergessen habe anzuhängen.


entschuldigung :(

Atrus2711
06.06.2012, 07:55
καλημέρα,
Von welchem Form reden wir?

dergrieche
06.06.2012, 08:06
frm_NewType_under
frm_NewMake_under
frm_NewRange_under

und wenn später noch mal sowas vorkommt, müsste ich den prozess ja langsam verstanden haben :-)

Atrus2711
06.06.2012, 08:31
Diese 3 Formulare wissen nichts davon, dass sie irgendwo als Ufo eingesetzt werden. Der Einsatz als Ufo erfolgt einfach durch "Einbetten" der Formulare in die Ufo-Gucklöcher im Hauptform. Und dabei wird dort dann auch dafür gesorgt, dass das Ufo immer Details zum aktuellen Hauptform-Satz aufnimmt bzw. anzeigt. Wenn der HF-Satz neu angelegt wird, geschieht das einen Augenblick vor dem Aktualisieren des Ufos, so dass das Ufo auch den neuen HF-Satz ergänzen kann; er existiert ja "seit jetzt gerade".

Wo ist also das Problem?

dergrieche
06.06.2012, 08:50
Mir ist klar, dass die Ufos nicht wissen, dass sie Ufos sind.
Das Problem ist die Praxis. Ich will n neues Make und da steht nicht der vorher ausgewählte (im frm_Selector ausgewählte Wert bei Type) nicht drin ^^

Atrus2711
06.06.2012, 09:06
Führe mich mal, wie ich das nachstellen kann. Ich blicks gerade nicht, wo das auftritt.

dergrieche
06.06.2012, 09:15
Beim Öffnen der DB erscheint frm_Start, also schön öffnen lassen :-)
nun klicken auf:
- "Management structure"
- dann in de Liste "truck" auswählen
- es öffnet sich die nächet Liste. dort nichts auswählen und auf "new" gehen.
- es öffnet sich ein pflegeformular (frm_NewMake)

Dieses Formular besteht aus einem Unterformular (frm_NewMake_under).
Beim Öffnen sollte man bereits drei Einträge sehen:
A; B; H -> alle mit dem Type "TrucK" (logisch)

Nun gehe mal auf neuen Datensatz und füge "Bike" hinzu. Dort soll nun bei "Type" (Product Division) automatisch Truck angezeigt werden, wenn ein neuer Datensatz erstellt wird.

Zusätzlich soll im Datensatz von der tblMake soll der Primärschlüssel "type_id" vom Eintrag "Truck" gespeichert werden. Damit hätte ich den neuen Datensatz mit dem Eintrag Truck :-)

dergrieche
06.06.2012, 09:16
Ich mus jetzt zu einer Betriebsversammlung!
bin iner stund wieder da. DAS WID VLLT interessant!!! geil ^^

Storch
06.06.2012, 09:19
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 ?????

Atrus2711
06.06.2012, 09:31
Ich kann dir nicht folgen (in die Versammlung eh nicht, aber auch hier nicht):
- es öffnet sich die nächet Liste. dort nichts auswählen und auf "new" gehen.
Wie wähle ich denn ist der nächsten Liste nichts aus? Das ist gar nicht vorgesehen!

Nun gehe mal auf neuen Datensatz und füge "Bike" hinzu.
Auf neuen Datensatz, aber wo?

Dort soll nun bei "Type" (Product Division) automatisch Truck angezeigt werden, wenn ein neuer Datensatz erstellt wird.
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.

stuz1
06.06.2012, 09:35
•Übergabe der Typenummer als sog. OpenArg bei Docmd.OpenForm

Siehe Beitrag Nummer #3

Du könntest dann höchstens die tpye_ID in den openArgs

Atrus2711
06.06.2012, 09:38
@stuz:
ok, prior art. :) Unser hellenischer Freund hats aber nicht aufgeschnappt, ich selbst auch nicht.

dergrieche
06.06.2012, 11:43
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 :-)

dergrieche
06.06.2012, 11:50
@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

Atrus2711
06.06.2012, 12:12
#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.

dergrieche
06.06.2012, 13:31
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


•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


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).

Atrus2711
06.06.2012, 13:52
das mit defaultvalue und sperrung steuern habe ich nicht verstanden
Doch hast du. Weil du (!) das hier verlangst:
wenn der anwender eben auf "Bike" klickt, soll halt in "Make" als voraussetzung "Bike" automatisch eingetragen werden
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).

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)
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):

'Im Formularcode ganz oben, wenns nicht eh schon da steht
Option Explicit
'Dann das hier, das ist jedenfalls neu:
Dim m_TypeID As Long 'Lokale Speichervariable für die darzustellende Typenr

'Eigenschaft (Property) prpTypeID: Schleuse zum Ein- und Ausgeben der darzustellenden TypeID von/nach außen
'Schleuse nach außen:
Public Property Get prpTypeID() As Long
prpTypeID = m_TypeID
End Property
'Schleuse nach innen:
Public Property Let prpTypeID(ByVal vNewValue As Long)
m_TypeID = vNewValue
End Property

Public Sub LoadMakes()
'Lädt die Makes des aktuellen Types bzw. alle
If m_TypeID = 0 Then
'Typ nicht vorgegeben: alle Makes zeigen
Me.RecordSource = "SELECT * FROM Makes" 'alle
Else
'Typ vorgegeben
Me.RecordSource = "SELECT * FROM Makes WHERE F_Type_ID = " & m_TypeID 'ergibt Makes des aktuellen Typs
Me!txtTextfeldMitDerTypeID.Defaultvalue = m_TypeID 'Standardwert!
Me!txtTextfeldMitDerTypeID.Locked = True 'Sperren!
End If

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:

If Len(Nz(Me!TextfeldMitDerTypeID)) > 0 Then
Set frmMakes = New Form_frmMakes 'Formularzugriff beginnen:
With frmMakes
.prpTypeID = Me!TextfeldMitDerTypeID 'TypeID in Property eintragen
.LoadMakes 'passende Makes laden; dabei auch Type sperren und vorbelegen
.Visible = True 'anzeigen :)
End With
Else
MsgBox "Bitte zunächst Type wählen oder anlegen!", vbCritical, "Kein aktuelles Fahrzeug"
End If

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

dergrieche
12.06.2012, 09:09
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???? :D

Atrus2711
12.06.2012, 09:24
Der Code muss ins Formular, das die Makes anzeigt.

Ich bin gerade sogar am grübeln, ob das mit dem modell so passt?
Warum? Wo klemmts?

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
Versteh ich nicht. Wo ist das Problem? Waren wir nicht schon weiter?

dergrieche
12.06.2012, 09:56
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

Atrus2711
12.06.2012, 10:30
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 :) ). 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?!

dergrieche
12.06.2012, 10:35
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.

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

dergrieche
12.06.2012, 10:59
Name = Modelbezeichnung.
Natürlich ist mit der Baureihe klar, welches Modell gemeint ist, aber es fehlt noch eine Bennennung für die Variante. Ich finds sinnlos, aber es ist hier gewünscht.

In dem Fall zB: C7H/123/S12/4x2/ABCD
Wi gesagt, sinnlos - aber gewollt - also wird der "Name" später einfach da stehen damit da was steht ^^

Atrus2711
12.06.2012, 12:31
Heißt also: Der VW Golf (=Baureihe) kommt als Variante 90-PS-Benziner und 105-PS-Diesel (= Modelle, "Objekte")?

dergrieche
12.06.2012, 12:48
genau :)

Atrus2711
12.06.2012, 13:10
Dann ist die Hierachie aber doch so:
Type->Make->Range->Model
Und das Model "erbt" von Type und Range einige "Pflichteigenschaften" und steuert selbst eigene Eigenschaften zu.

Beispiel Golf 90-PS-Benziner:
Type = PKW
Make = VW
Range = Golf
Model = GTI (keine Ahnung :) )
Der Golf GTI muss, da er PKW ist, meinetwegen die Eigenschaften "Anzahl Türen" und "Leergewicht" haben. Da er aber zusätzlich ein Golf ist, muss er etwa die Eigenschaften "Werksradio-Name" und "Rückbank umklappbar" liefern, weil alle Gölfe diese Wahlfreiheit gewähren. Und als GTI gibts dann noch die Zusatzeigenschaft "Auspuffrohr vergittert j/n". Insgesamt ergeben sich so für den Golf GTI 5 Eigenschaften als Pflichtenheft. Wäre es ein Nicht-GTI-Golf, bliebe es bei 4, weil Nicht-GTI-Gölfe beim Auspuff keine Wahl bieten. Und wäre es kein Golf, sondern ein Colt, erhält der erstmal nur die Anzahl Türen und das Leergewicht (Colt-Spezifika habe ich ja keine genannt).

Für die im Pflichtenheft resultierenden Eigenschaften kann es nun für jedes Model Werte geben. Einige dieser Werte sind Freitexte, andere sind an einen Vorrat gebunden. Diese Vorräte könntest du dann über Kombifelder anbieten (wohlgemerkt: dabei die Klartexte übergeben, nicht die Fremdschlüssel, da es ja auch vorratsfreie Werte geben darf).

dergrieche
13.06.2012, 08:41
ich weiß wirklich nicht, wie ich das anlegen soll :-(

da die unterschiedlichen Informationen/ Daten doch nur EIN einziges Attribut sind, wird wenn ich in einem Kombifeld was ändere, alle Einträge geändert :-(
Ich hab noch nich verstanden, wie ein "Truck" die "Optionen" haben kann. Die tblValue muss jede einzelne Kombinationsmöglichkeit der Trucks beinhalten?! Ist das korrekt? Sry, dass ich das einfach nicht verstehe, aber es hat einfach noch nicht "klick" gemacht.

Könntest du mir, wenn ich dir meine aktuelle DB einmal hochstellen würde, mir da mit einer "möglichen" Lösung weiterhelfen? Ich komm einfach nicht drauf :-(

Atrus2711
13.06.2012, 09:04
Probieren wirs. Lad mal hoch. Oder ich bau einfach mal ein Modell auf, wie ich das mit den Gölfen und Colts aufbauen würde (da fallen mir die Beispiele leichter, weil ich mit Großfahrzeugen nicht so vertraut bin).

dergrieche
13.06.2012, 09:23
Habe für dich PKW hinzugefügt mit Beispiel, mein Lieblingshersteller ... auch wenn ich von so einem noch träume :-D

Aber bei der Hierarchie gibts es keine Unterschiede.
-> Wenn du nach der Hierarchieauswahl ins neue Formular "frm_Selector" kommst. Dort will ich ein Ufo einbauen die "Suchmaske". Die soll mit Kombinationsfeldern sein (wenn möglich).


Frage:
wie sind im Form frm_Selector in den Listen lst_make & lst_range keine Datensatzherkünfte? -> und wieso funktioniert das?

Atrus2711
13.06.2012, 10:25
Hier schon mal ein besseres Datenmodell... baue die DB gerade auf.

Atrus2711
13.06.2012, 11:04
wie sind im Form frm_Selector in den Listen lst_make & lst_range keine Datensatzherkünfte? -> und wieso funktioniert das?
Das sind abhängige Listenfelder. Die Datenherkünfte werden im Ereignis Nach Aktualisieren des übergeordneten Listfeldes über VBA-Code neu aufgebaut (such mal im Code nach Rowsource).

dergrieche
13.06.2012, 12:09
Thema lst-Felder -> kapiert :-) danke

Modell:
1. Hierarchie
dadurch, dass du in der tblBaureihen den Typ und den Hersteller vereinst, gibt es keine Komplikationen und ich vermeide das andauernde "Bezug" nehmen, da es dort ganz klar wird. Dann ist wieder normale Hierarchie, ... verstanden! :-)

2. Pflichtenhefte
- tblTypenEigenschaften. was habe ich davon? Anmerkungen? Pflichtangaben zum Typ -> kann ich nicht in der tblTypen als remark setzen?
- Des Selbe für Modelll und Baureihen.
-

3. Einstellbare Größen
-> verstehe ich nicht. sage ich denn nicht schon in der zB tblEigenschaften, die benötigte "Pflicht"Eigenschaft? Was steht dann in der tblEigenschaften_1? etc.


Da brauch ich noch ein bisschen Erklärung :-)
Danke!

Atrus2711
13.06.2012, 12:35
ad 2) Pflichtenheft
Ein Pflichtenheft sagt: "was muss erfüllt werden", d.g. welche Eigenschaften sind überhaupt mit Werten zu belegen. Ein Truck braucht sich z.B. nicht um ein Videosystem für Passagiere zu kümmern, dafür hat ein Bus keine Sattelkupplung und keine Kippvorrichtung/Hebebühne. Auch Baureihen könnten Pflichten haben; vielleicht haben ja die Colts allesamt die Pflicht, sich zum Thema "umklappbare Rückbank" zu äußern, während andere Baureihen sich diese Frage gar nicht stellen. Und auch die Modelle als "verfeinerte Baureihen" könnten Pflichten haben, z.B. ist der Golf GTI mit einem optionalen Nachbrenner im Auspuff lieferbar, während andere Gölfe und andere Modelle das gar nicht bieten.

In meinem Modell können also alle Hierarchieteile (Typen, Baureihen, Modelle) "Pflichten" erzeugen. Die Vereinigungsmenge aus allen Teilpflichten ergibt das gesamte Pflichtenheft. Ein Fahrrad muss sich z.B. als Fahrrad keine Gedanken um Tankinhalt oder Motorisierung machen, erfordert aber z.B. die Angabe der Schaltung und der Fahrerposition (Sitz/Liegerad). Fahrradbaureihen können dann z.B. Federungen vorsehen (bei ungefederten Baureihen dann halt nicht), und Fahrradmodelle fordern dann vielleicht die Reifengrößen oder die Rahmenhöhe an.

ad 3) Eingestellte Eigenschaften
Die Erfüllung der geforderten Pflichten - das konkrete Ausgestalten der geforderten Eigenschaften - ist dann in den Eingestellten Eigenschaften abgelegt. Da steht drin, wie das Modell die Pflichten erfüllt. Beispiel Golf GTI: als PKW muss er sich zum Leergewicht äußern: "1025 kg", als Golf außerdem zum Thema Umklappbare Rückbank (ja, asymmetrisch), und als GTI zusätzlich zum Nachbrenner: ja, hat er. Ein Normalgolf stellt sich die Frage nach Umklapp und Nachbrenner u.U. erst gar nicht und äußert sich nur zum Gewicht.

Die Tabelle tblEigenschaften ist lediglich ein Verzeichnis der überhaupt möglichen Größen: was für Kenngrößen kommen überhaupt vor. Menschen haben an Eigenschaften z.B. Gewicht, Geschlecht, Größe, Haarfarbe; Fahrzeuge haben ebenfalls Eigenschaften, die es zu belegen gilt und die von Typ, Baureihe und Modell abhängen. Und falls die möglichen Belegungen der Eigenschaft an einen Vorrat gekoppelt ist, steht der in den Eigenschaftsvorräten: Bremsen können Scheibe, Trommel, Retarder oder Magnetbremsen sein. Rückfahrwarner können akustisch, optisch oder kamerabasiert sein. Aber für Anzahl der Schraubenlöcher in der Felge gibt es keinen Vorrat: ich kenne von 3 (Smart) bis 12 (Trucks) alles mögliche...

Die tblEigenschaften kommt im Datenmodell 4x vor: überall dort, wo Eigenschaften "benutzt" werden: bei den drei Teil-Pflichtenheften sowie bei den eingestellten Eigenschaftswerten. Die Tabelle gibt es in der Datenbank aber nur einmal.

Die DB ist im Gerüst soweit fertig, ich füge gerade noch ein paar schöne Demofälle dazu. Formulare gibts aber noch keine. Das ist auch sinnlos, solange das Datenmodell nicht wasserdicht ist.

Atrus2711
13.06.2012, 12:56
Hier die DB. Hangel dich am besten mit dem kommentierten Datenmodell vor Augen da durch.

dergrieche
13.06.2012, 13:47
Mach ich. melde mich bei Fragen. Danke!

dergrieche
13.06.2012, 14:26
Ok, ich meine es verstanden zu haben.

Die Hierarchie zieht sich im Endeffekt bis zu der tblEingestellteEigenschaftswerte durch. Typ und Hersteller = Baureihe -> Modell -> Eigenschaftswerte. Klar, ein modell hat ja mehrere Eigenschaften. deine tblEingestelleEigenschaftswerte spiegelt meine tblValue wieder. und deine tblEigenschaften meine tblProperties. Und es "endet" in der Zusammenführung der details in der Vorräte.

Dann knüpf ich jetzt noch folgendes an. Das kam gerade aus einer Besprechung -.- Zeitliche Darstelleung der Produktion. Es soll das gewünschte Automobil zeitlich eingeteilt zB. Wann ist unser PKW - VW - Golf - GTI in bau. Wenn jemand zB einen Prototypen oder Benchmark von diesem GTI will, muss der ja gebaut werden. (ich hab denen nix versprochen, hab gesagt, ich mach mich mal schlau ob das machbar ist ^^)
-> Wann ist Bandauflage, wann ist das ding fertig. Das sind die Rahmenbedingungen für die Zeitplanung. In diesen Rahmenbedingungen unterscheiden wir hier zwischen in folgender Reihenfolge: Bandauflage, Motor, Rohbau, Lackierung, Montage, Audit.
Und ich muss einen "Verantwortlichen" für das Fahrzeug haben. -> kann das nicht einfach in einem "remarK" dargestellt werden? Bzw. es ist ja eine wie du eben nanntest "etwas was erfüllt werden muss"?!

Ist das denn machbar? (wäre natürlich echt super, wenn das klappt.)
Rein theoretisch müsste ich an die tblEingestelleEigenschaftswerte eine tblTimeline hängen. Dort sage ich Rohbau usw. mit Datumsfelder. zB:
tblTimeline
- timeline_ID
- F-Modell_ID
- rohbau_beginn
- rohbau_ende
- montage_beginn
- montage_ende
- usw.
Dann ist ja klar, wann was wie wo?? Was habe ich nicht bedacht? Ist das so simpel zu realisieren?

Im Endeffekt ist natürlich ne tolle Grafik gewünscht in der gezeigt wird, von wann bis wann was passiert. (siehe Word.datei) Aber ich denke, dass die auch zur Not mit einfachen Datumsangaben zufrieden sind.

EDIT: Anhang vergessen

Atrus2711
13.06.2012, 14:37
Es ist sogar noch einfacher.
rohbau_beginn, rohbau_ende, montage_beginn und montage_ende sind einfach weitere Eigenschaften-Datensätze, die modellabhängig sind, mglw. auch abhängig von Baureihe oder Typ.

dergrieche
14.06.2012, 12:12
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.

Atrus2711
14.06.2012, 12:49
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.

dergrieche
14.06.2012, 13:15
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?

Atrus2711
14.06.2012, 14:10
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.

dergrieche
14.06.2012, 14:34
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 :-)

Atrus2711
14.06.2012, 14:42
tblData ist ein unschöner Name. Daten ist alles. Das sind Eigenschaftskategorien!

Type, Hersteller und Range sind doch schon vorher ausgewählt? :-)
Wenn das so ist, dann mach das so.

Wie pflege ich meine tblEigenschaftsvorräte & meine tblEigenschaft ?
Mit ein paar Formularen?!

dergrieche
14.06.2012, 14:52
Zitat:
Wie pflege ich meine tblEigenschaftsvorräte & meine tblEigenschaft ?

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?

Atrus2711
15.06.2012, 09:46
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.

dergrieche
20.06.2012, 09:02
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?

Atrus2711
20.06.2012, 09:18
Jedoch klappt das noch nicht so ganz mit dem cbo feldern, wie ich das gerne hätte.
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.
Private Sub Form_Current()
Me!stock_name.RowSource = "SELECT tblPropStock.stock_ID, tblPropStock.stock_name, tblPropStock.f_prop_ID " _
& "FROM tblPropStock " _
& "WHERE f_Prop_ID = " & Me.prop_ID & " " _
& "ORDER BY tblPropStock.stock_name"
End Sub

dergrieche
20.06.2012, 12:00
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 -.-

Atrus2711
20.06.2012, 12:29
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? :)

dergrieche
20.06.2012, 12:38
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 -.-

Atrus2711
20.06.2012, 12:51
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.
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.

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?
Ebenfalls in den EingestelltenEigenschaften. Da steht drin: Modell X hat in Eigenschaft Y den Wert Z.

dergrieche
20.06.2012, 13:00
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?


:-)

Atrus2711
20.06.2012, 13:06
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
Ja, darum gings doch seit Tagen.... :p

Ich will ja, dass der Anwender aus den bestehenden Vorräten, seine aussucht, dem ensprechend in der tblValue nach seinem Wunsch gesucht wird.
Moment. Der User hat sich über die linke Formhälfte über Type, hersteller und Baureihe für ein Modell entschieden und sieht jetzt dessen verlangte Eigenschaften und deren Erfüllung. Das ist die Anzeige vorhandener Modelle.

Für die Suche nach Modellen anhand von Eigenschaften kann es wohl nicht sinnvoll sein, ein Modell suchen zu müssen. Da würde ich doch eher ein paar neue Formulare aufbauen, die anhand der Vorgaben die Modelle suchen.... Diese Formulare können sich aus den bisherigen Forms ergeben, sind aber eben separat zu halten, da z.B. das Eigenschaften-des-aktuellen-Modells-Ufo eben nicht als Modellsuche taugt.

dergrieche
20.06.2012, 13:22
Darum gings es seit Tagen, stimmt ... Aber ich habs ja noch nicht umgesetzt, und ich kapier des meist erst dann zu 100% wenn ich es umsetze :-)
Aber bzgl. dem VBA werde ich dafür deine Hilfe benötigen. Wenn ich soweit bin, werde ich mich wie immer melden ^^


Ja, der User hat sein model ausgewählt. Ein Model ist aber nicht = ein fertig "selektierter Truck". Ein model ist wie der "Golf GTI" hier ein "4x2 TT". Insgesamt haben wir aktuelle 14 Modelle. Ein Model kann aber unterschiedliche Konfigurationen haben, daher können wir mehrere Modelle habe mit unterschiedlichen Konfigurationen -> mehrere Gold GTI, der eine hat 130 PS, der andere 250 PS :-)
es ist zwar das gleiche Model, aber nicht das Selbe Fahrzeug. Hier muss ich viele ggf viele gleiche Fahrzeuge darstellen.

Der Anwender muss sich den gezielten Truck auswählen, damit er ihn verwalten kann "Rohbau Beginn, Rohbau Ende, usw. usw."
Ich hatte mir gedacht, dass der Anwender um seinen Truck zu finden, nun ich eine Maske bereitstelle, dass er sagt: Truck - Percedes-Renz - Golf - GTI => dann stellt er sich die Frage: welchen Golf suche ich noch mal? Stell dir vor es gibt 1000 GTI's mit unterschiedlichen Konfigurationen ... von PS bis Farbe. ggf will der Auditor nen gleichen Wagen mit anderen Farbe, weil ein gelbes Auto zB andere Korrosionsschwächen hat? Oder was auch immer sein Grund ist. Irgendwie muss ich doch nun die Möglichkeit bereitstellen, den gezielten Truck aus der tblValue zu finden.

Wie würdest du das denn realisieren? Noch mal kurz gesagt, wichtig ist, dass der Anwender sein gezieltes Fahrzeug findet, damit er darauf "aufbauen" kann/ arbeiten/ planen kann.

Atrus2711
20.06.2012, 13:47
Ein Model kann aber unterschiedliche Konfigurationen haben
Das ging unter. Modelle sind bisher die tiefste Hiearchiebene. Ein 250-PS-Golf-GTI und ein 130-PS-Golf_GTI müssten bisher zwei Modelle sein. Vielleicht sind es dann besser zwei Varianten desselben Modells, also eine weitere Ebene.

Zum Suche-Bearbeitungs-Dilemma:
Bisher arbeiten wir an der Bearbeitungsseite: das aktuelle Modell zeigt sein Pflichtenheft und dessen Erfüllung durch die eingestellten Werte. Wenn die Auswahl des Modells nun nicht nur durch die Entlanghangeln an Typ-Hersteller-Baureihe geschieht, sondern auch durch hierarchiefreie Suche nach einer "Eigenschaftskonfiguration", dann ist das eine neue Anforderung. Bau dir halt dafür neue, eigene Formulare. Die resultieren letztlich aber in einer Trefferliste aus passenden Modellen, deren jedes man dann in den bisherigen Formulare bearbeiten und kopieren könnte.

So ein Modellsuchformular nach Eigenschaften könnte so aussehen:

Man wählt, welche Eigenschaften (maximal: alle) man vorgeben will (z.B. Typ, Achsanzahl, Übersetzung).
Für diese gewählten Eigenschaften werden in einem Ufo die gewünschten Werte erfragt: Gesuchter Typ sei Truck, gesuchte Achsanzahl sei 3, gesuchte Übersetzung sei 3,8:1.
Diese Suchebegriffe stehen in einer Tabelle "Suchparameter". Bei Einzelwerten ist die Suchbedingung dann "Achsanzahl = 3". Bei Alternativwerten (Achse = 2 oder 3) sollte die Bedingung dann sein: Achsanzahl In (2,3)
Die Modellsuche sucht nun die passenden Modelle, indem die Teilkriterien der Tabelle zusammengesetzt und angewendet werden.

dergrieche
20.06.2012, 14:14
Moment, ggf hab ich mich falsch ausgedrückt. Ein und das selbe Fahrzeug kann natürlich nur eine Konfiguration haben. Das ist klar. Wenn du aber zB einen Golf GTI bei mir bestellst, willst du ja einen "bestimmten" Golf GTI. Den werde ich dir bauen. Dieser Golf GTI, den muss ich dann in der DB hinterlegen. Da muss ich dann planen, wann der fertig ist usw. damit du ihn pünktlich vor die Haustüre kriegst.

Hier soll das Fahrzeug dann zB auf die Teststrecke, oder irgendwo als Demo oder Benchmark ausgestellt werden, was auch immer.


Was ändert das denn an der Hierarchie? Nichts? Es gibt doch nichts, unter Model? Oder kommt da das genaue Fahrzeug hin? Wird das nicht mit der tblValue (EingestellteEigenschaftswerte) gewährleistet? Meiner Meinung nach ja, da die value_ID mit der f_model_ID und der f_prop_ID eindeutig das Fahrzeug identifizieren?! Jain? Oder muss ich für deinen Golf GTI eine sogennante Fahrgestellnummer haben, mit der das Fahrzeug eindeutig identifizerit werden kann/ wird. Mit dieser Nummer kann man ja in der Produktion die Stückliste einsehen.

In der DB hier, würde ich sagen, dass dein GOLF GTI die nummer X is, das meinst du, oder?


bzgl des Suchmasken-Dilemmas:
Jap, genau so eine Suchfunktion ist gewünscht. Und es sollte seinen Bezug auf das Modell nehmen. Wenn der Anwender schon vorher seinen "Golf GTI" ausgewählt hat, muss mir die Suchmaske ja keinen Polo mehr anzeigen.

Leider kann ich mir gerade nicht erschließen, wie ich das mit der tblSuchparameter anstellen soll. Den logischen Hintergrund meine ich verstanden zu haben. Alles was da drin ist, nachdem wird gesucht werden können. Aber was genau steht da drin? fertige Trucks? oder nur wieder die Optionen? Die könnten wir ja dann widerum aus der tblPropStock holen?

Atrus2711
20.06.2012, 14:46
Die Diskussion hatten wir auch schon mal (#28 (http://www.ms-office-forum.de/forum/showpost.php?p=1452551&postcount=28)): "Mit einem Modell kann ich nicht fahren und kann keine Beule reintreten. Das kann ich nur mit Fahrzeugen (Modellinstanzen).". Ein Modell kann auch nicht die Farbe blau haben, da ein blauer Golf GTI ein instanziierter Golf ist. Das Modell Golf GTI bietet zwar die Eigenschaft Farbe, aber da nicht alle GTIs blau sind, ist das nur eine Eigenschaft. Eingestellt wird diese Eigenschaft nur für echte Blechkisten. Das ist dir offenbar noch nicht klargeworden.

Wenn es also wirklich um den Bau von Fahrzeugen (mit Blaulackier- und Beulenfähigkeit) geht, dann fehlt in der Tat noch eine Tabelle: Fahrzeuge. So wie ich das deute, sind das bei euch Prototypen (oder habt ihr eine Liste aller existierenden Gölfe weltweit?!). Also wären die Prototypen die "ausgeformten Modelle": man kann Beulen reintreten und sie auf die Teststrecke stellen.

Also:
Es gibt doch nichts, unter Model? Oder kommt da das genaue Fahrzeug hin? Wird das nicht mit der tblValue (EingestellteEigenschaftswerte) gewährleistet?
Ja, da kommt das Fahrzeug hin. Das Fahrzeug wird ja auch einen Projekt/Prototypnamen haben?! Es heißt ja vermutlich nicht "3-Achser-mit-450-PS-und-Nachbrenner-den-kein-TÜV-abnimmt".?! Das ist vielleicht die Kette der eingestellten Werte, aber nicht das Fahrzeug.

Meiner Meinung nach ja, da die value_ID mit der f_model_ID und der f_prop_ID eindeutig das Fahrzeug identifizieren
Bedenke, dass nicht alle Eingestellten Eigenschaften Fremdschlüssel der Eigenschaftsvorräte sind. Für Maße (4,20 m) beispielweise gibt es sicher keine Vorratstabelle; die Autos werden so lang wie sie wollen. Da steht also dann nicht die Kennzahl für 4,20 drin, sondern 4,20 direkt. Und ich bin auch nicht sicher, dass Modell-ID und Prop-ID in Kombination eindeutig sind. Diese "Wer-hat-was"-Zeile könnte sich wiederholen; 6 Airbags im GTI kann man als eine Eigenschaft "6 Airbags" ablegen, oder (besser) als 6 Zeilen der Eigenschaft "Airbag".

Jap, genau so eine Suchfunktion ist gewünscht. Und es sollte seinen Bezug auf das Modell nehmen.
Also "Vorauswahl" nach Type, Hersteller, Baureihe, Modell (?), so dass dann z.B. nur die Golf GTIs in Frage kommen: der rote mit 250 PS und der gelbe mit 130 PS. Aus diesen zwei vorselektierten Modellen wird dann mit Achsanzahl etc. weiter gefiltert?

Die Parametertabelle könnte so aussehen: ein Textfeld "Kriterien".
Kriterien
[Achsanzahl] IN (2,3)
[Nachbrenner] = True
[KonservativerWurstblinker] = False
[Länge] > 4,20
Für die modellbegrenzten Fahrzeuge müssen diese Angaben dann ermittelt werden. Da kann eine dynamisch zusammengesetzte SQL helfen.

PS: habt ihr eigentlich keine Informatiker im Haus, oder hab ich das gar schonmal gefragt?! :grins:

dergrieche
20.06.2012, 15:28
Jap, die Diskussion hatten wir schon mal. Gut also, dass wir nun den gemeinsamen Nenner gefunden haben :-)

Ja genau, es geht hier um prototypen. Natürlich hat auch jeder Prototyp einen Namen. Die Prototypen sind ausgeformte Modelle. Na, ... ich hoffe doch mal schwer, dass man KEINE Beule reintreten kann :-D

Ok, also kommt nach/ unter der tblModel die tblVehicle. Die schiebe ich zwischen die tblModel und der tblValue. Die besteht aus:
- vehicle_ID (pk)
- f_model_ID
- f_value_ID
- vehicle_name

Was wird hier gesagt?? Ich will doch jetzt eigentlich in der tblFahrzeuge (tblVehicle) sagen, wie ein Fahrzeug konfiguriert ist. braucht dann nicht EIN Fahrzeug auch EINE ID für seine Konfiguration? So wie in der tblType klar wird, dass "Truck = 1; Engine = 2; usw. ..." ist?
-> wo ist dann der Sinn der tblValue? Was mache ich mit der? was steht da drin?



Also "Vorauswahl" nach Type, Hersteller, Baureihe, Modell (?), so dass dann z.B. nur die Golf GTIs in Frage kommen: der rote mit 250 PS und der gelbe mit 130 PS. Aus diesen zwei vorselektierten Modellen wird dann mit Achsanzahl etc. weiter gefiltert?

Ganz genau. Dann soll diese tolle Suchmaske kommen, mit der ich die maximalen Eigenschaften filtern kann, aber wenn ich zb nur nach Farbe filtern will, sollen alle die die Farbe rot haben angezeigt werden.




Du hast das schon gefragt und ich musste ganz bescheiden "jain" sagen ;-)

Zum Hintergrund, warum ich das mache. Ich hatte letztes Jahr eine DB erstellt für die Verarbeitung von Marktdaten. hatte da auch unterstützung von einem IT Manager, hat wunderbar geklappt.
Für dieses Praktikum wurde mir gesagt, -> wir brauchen lediglich eine DB in der wir unsere Fahrzeuge auflisten können, damit wir sehen, was wir haben. und nun sind wir da wo ich bin -.-

Soviel zum Thema "Stellenbeschreibung" :-D

Atrus2711
20.06.2012, 15:42
tblVehicle solte so aussehen:
- vehicle_ID (pk)
- f_model_ID
<strike>- f_value_ID</strike>
- vehicle_name
und hängt unter den Modellen, aber zu den Values (EingestellteEigeschaften) hat sie keinen Bezug. Vielmehr sind es nun die Prototypen, die Eingestellte Eigenschaften haben. Die Eingestellten Werte eines Prototyps sagen aus, wie der Prototyp das Gesamtpflichtenheft erfüllt, das sich aus den Typ-, Baureihe- und Modell-Pflichten ergibt. Darum fliegt die valueID aus den Fahrzeugen raus.

Der Prototyp 42 (PKW VW Golf GTI A mit 130 PS) muss liefern:

als PKW z.B. die Anzahl Türen (eingestellt: 4)
als Baureihe Golf z.B. die Golf-Spezialeigenschaft "Werksradio" (eingestellt: Beta)
als Modell GTI z.B. den Nachbrenner (eingestellt: nein)
als Prototyp Super 130 PS die "A-Spezialeigenschaft" (eingestellt: X)


Der Prototyp 99 (PKW VW Golf GTI B mit 250 PS) muss liefern:

als PKW z.B. die Anzahl Türen (eingestellt: 4)
als Baureihe Golf z.B. die Golf-Spezialeigenschaft "Werksradio" (eingestellt: Gamma)
als Modell GTI z.B. den Nachbrenner (eingestellt: ja)
als Prototyp Super 130 PS die "A-Spezialeigenschaft" (eingestellt: Y)


Zur Suchmaske hast du ja schon einen Anstoß bekommen. Baus halt mal.

dergrieche
20.06.2012, 15:47
Alles klar.
Ja bin dabei, gebe mein Bestes :-)

was mache ich nun mit der tblValue? wozu benötige ich die noch? Schließlich wird doch nun alles in der tblVehicle dargestellt.

Atrus2711
20.06.2012, 15:50
was mache ich nun mit der tblValue? wozu benötige ich die noch? Schließlich wird doch nun alles in der tblVehicle dargestellt.
Irrtum. Vehicles und Properties sind m:n: Ein Vehicle kann viele Eigenschaften "ausprägen", und eine Eigenschaft kann in vielen Vehicles auftreten (m:n). Die Values vermitteln: wer (Prototyp 42 = A-GTI) hat in welcher Eigenschaft (6 = Achsenanzahl) welchen eingestellten Wert (2 = 2 Achsen).

dergrieche
20.06.2012, 15:55
aaa, ok :-)

j' ai compris. merci

dergrieche
21.06.2012, 15:56
ich kriegs net hin -.-

ich weiß nicht, wie ich dieses Suchmaskenformular erstellen soll. Rein theoretisch wüsste ich wie. Praktisch tut es das aber nicht.


Ich muss ganz klar die tblProperties und die tblPropStock nehmen. Die Properties zeigt mir die allgemeinen Eigenschaftenbezeichnungen und die tblPropStock die genauen Eigenschaften. Dein Code klappt mit der Eingrenzung auf die tblProperties. Aber dieser "Sucher" ist ja was ganz "unverbindliches". Er bindet sich ausschließlich an seinen Inhalt. Was nicht drin steht, kann nicht ausgewählt werden.


Nächstes Anliegen:
Irrtum. Vehicles und Properties sind m:n: Ein Vehicle kann viele Eigenschaften "ausprägen", und eine Eigenschaft kann in vielen Vehicles auftreten (m:n). Die Values vermitteln: wer (Prototyp 42 = A-GTI) hat in welcher Eigenschaft (6 = Achsenanzahl) welchen eingestellten Wert (2 = 2 Achsen).
Kann ich tblValue mit der tblVehicle den platz tauschen?
Begründung: Die Konfiguration eines Fahrzeuges bestimmt den Namen eines Fahrzeuges. Z.B ein MAN TGX 18.440. So heißt des Ding. Wenn man sich mal auf der Internetseite des mal anschaut, selektiert man dort ein Fahrzeug nach bestimmten Kriterien. als erstes die Baureihe (TGX) usw. die 18 steht für 18 Tonner und die 440 für 440PS. Wenn ich also nen 480PS nehme in dem Selektor, dann heißt er TGX 18.480.


Gedanke beim Tausch:
ein Model besteht aus vielen Eigenschaften (anstatt das Fahrzeug). Bestimmte Eigenschaften bilden ein Fahrzeugnamen (wie im vorhergegangenen beispiel). Dieses Fahrzeug besteht aus bestimmten Eigenschaften.
Ist das machbar? Weil ich hab mich vorhin mit dem produktmgmt echt gefetzt :-D das ist meiner meinung nach nur ein Luxusproblem, für die, die zu Faul sind, vorher nen namen für das Ding einzutippen.


EDIT
Fehler: Model besteht aus Eigenschaften daher muss die Properties verknüpft sein, ganz klar. Vehicle gehört jetzt nur noch an die tblValue einfach angehängt, um einen Namen zu genieren. Wie siehst du das?

Atrus2711
21.06.2012, 21:27
Hab heute und morgen ganztägige Termine. Melde mich am WE oder montag wieder.

dergrieche
22.06.2012, 08:13
alles klar. danke :-)

Atrus2711
25.06.2012, 08:38
Zu #71 inkl. Edit:

Ziel ist, die Einzelkriterien einer Suche (Achsanzahl = 3, Leistung = 440 PS) in einer Tabelle oder einer ähnlichen Struktur (Array, Collection, ...) zu speichern. Dieser Stapel von Kriterien wird aus den Einzelkriterien gebildet, für die man jeweils alle Props auf Werte eingrenzen kann.

Beispiel einer neuen Suche:

Erstes Kriterium: Auswahl der Prop Achsanzahl -> Eingabe des gewünschtes Werts 3 -> "auf Stapel legen"
Zweites Kriterium: Auswahl der Prop Motorleistung -> Eingabe des gewünschten Werts 440 -> "auf Stapel legen".
Am Ende der Auswahl: Stapel zum Gesamtkriterium vereinen und passende Fahrzeuge suchen.


Für das Einzelkriterium ist der Aufbau mit einem Form machbar:

Auswahl des zu untersuchenden Props
Auswahl oder Eingabe des gesuchten Werts (ggf. auch Mehrfachauswahl (?)); bei Props mit Vorrat kann dieser angeboten werden, aber es sind wohl auch vorratsfremde Werte möglich.
Ablage auf Stapel

Die Vereinigung des Stapels zum Gesamtkriterium wäre dann - je nach Stapelart - durch Join(Array, " AND ") oder durch Recordset-Iteration der Tabelle mit Verkettung der Teilkriterien möglich.

Zur Tabellenposition:
Verhicles sind benamste Kombinationen ("Sets") von Eigenschaften. Es bleibt daher so, wie es war. Ein Tausch ist nicht sinnvoll.

dergrieche
25.06.2012, 10:18
Der Ablauf des von dir genannten Beispiels ist verstanden.
Ich müsste also eine tblSuchparameter anlegen. Diese dient mir nur für die Suche. Die aus dem cboFeldern ausgewählten Werte werden dort drin abgebildet und ein bestimmter Code sucht zeigt mir dann alle Fahrzeuge an, die diesen Kriterien entsprechen.

Aber wie darf ich das mit dem Einzelkriterium verstehen?
Es wird doch lediglich im tblPropStock die aktuellen werte gesourced und in der tblvalue nach passenden ergebnisse, welche in verbindung mit dem primärschlüssel des fahrzeugnames stehen dargestellt.
Was ist mit der Frage gemeint, ob mehrfachauswahl möglich sei? ein fahrzeug hat ganz genau eine Achsenkonfiguration?

Des mit Vereinigung hab ich nicht verstanden, da geht es ja dann auch schon mit Code los :-D
Tabellenposition wird nicht verändert, habe mir da auch noch mal genauere gedanken gemacht, das ist einfach nicht sinngemäß dem was ich als Ziel haben will. (danke)

Atrus2711
25.06.2012, 10:25
Ja. Wenn das aber wirklich eine Tabelle werden soll (und kein Array, Collection oder eine andere VBA-Liste), dann sollte diese Tabelle in der endgültigen Version lokal im Frontend liegen. Denn die Suchparameter sind nicht so global wie die anderen Daten, sondern sehr persönlich: während User A nach einem 3-Achser sucht, kann User B nach ganz anderen Sachen suchen.

Der Aufbau der Tabelle ist in meinem Beitrag vom 20.06.2012 15:46 bereits umrissen.

Atrus2711
25.06.2012, 11:42
Aber wie darf ich das mit dem Einzelkriterium verstehen?
und
Des mit Vereinigung hab ich nicht verstanden, da geht es ja dann auch schon mit Code los :-D
Die Suchanfrage kann doch wohl aus mehr als einem Kriterium bestehen?! Gebe ich bei der Suche die Achsanzahl = 3 und die Leistung = 440 kW vor, dann sind das (erstmal) zwei Einzelkriterien. Das Gesamtkriterium wäre dann etwa so: ... WHERE Achsanzahl = 3 AND Leistung = 440

Was ist mit der Frage gemeint, ob mehrfachauswahl möglich sei? ein fahrzeug hat ganz genau eine Achsenkonfiguration?
Klar. Aber vielleicht suchst du nach einem Fahrzeug, das 2 oder 3 Achsen hat, weil du nicht auf genau zwei Achsen festgelegt bist. Damit erhöhst du die Chancen auf Treffer; Alternativen werden eher fündig. Wenn das nicht vorkommen soll, auch gut, dann ist es etwas einfacher.

dergrieche
25.06.2012, 12:43
ok problem lokalisiert. ja es soll die möglichkeit bestehen auch mehrere achsen zu suchen, ggf. sucht der User A alle Fahrzeuge mit einer bestimmten Achse und die können sowohl in einem 4x2 als auch in einem 6x2 oder 6x4 verbaut sein.

Ja die Suche soll aus mehreren Kriterien bestehen, hatte deine FOrmulierung falsch verstanden, sry. is schon korrekt so.



Ja. Wenn das aber wirklich eine Tabelle werden soll (und kein Array, Collection oder eine andere VBA-Liste), dann sollte diese Tabelle in der endgültigen Version lokal im Frontend liegen. Denn die Suchparameter sind nicht so global wie die anderen Daten, sondern sehr persönlich: während User A nach einem 3-Achser sucht, kann User B nach ganz anderen Sachen suchen.

Vorteile/ Nachteile ob es eine tbl oder ein Array/ Collection/ VBA-Liste wird (was is das? wie kann ich mir diese aufeinanderreihung vorstellen?) das muss ja tempörär irgendwo gespeichert werden?!

Atrus2711
25.06.2012, 13:13
Eine Tabelle ist eigentlich für spätere Massenverarbeitung per SQL gedacht. Eine Tabelle per VBA (Recordset) satzweise durchzunudeln ist zwar möglich, aber erfordert einen ziemlichen Wasserkopf an Verwaltung (relativ zum Nutzen; der Wasserkopf sind 3-4 Zeilen "mehr").

Ein Array ist eine Variable mit "Stapelfunktion". Normalerweise kann eine Variable ja immer nur einen Wert aufnehmen (Nachname = "Meier"); ein Array kann hingegen mehrere Werte "stapeln": Nachname(0) = "Meier", Nachname(1) = "Schmitt". Ein solcher Stapel liegt im Arbeitsspeicher (nicht auf Platte wie eine Tabelle) und kann recht fix durchgegangen werden. Das käme hier gelegen. Ein Beispiel dazu in meiner Demo "Suchkriterien kombinieren" im Code-Archiv.

Eine Collection ist ebenfalls ein "Stapel", allerdings etwas flexibler/anders in der Nutzung und etwas anders in der Speicherverwaltung.

dergrieche
25.06.2012, 13:34
Für die aktuelle Situation schätze ich das genau so wie du ein. Ein Array wäre hier am besten platziert.

Ich werde gleich mal sofort dein Beispiel mir ansehen und bei Fragen weiß ich ja, an wen ich mich wenden muss.
Ich bin nun soweit, dass ich fast die komplette "Datenadministration" aufgestzt habe. Wenn man also sich in der Datenadministration bewegt kann man so ziemlich fast alles anfügen, bearbeiten usw. usw.

Nun muss ich das "Such"Formular erstellen, und die Berichte mit dem gewünschten Output. Dann sollte es rein theoretisch fasttttt fertig sein.

Atrus2711
25.06.2012, 13:57
Wenns fertig ist, könnte das dein Erstling im Codearchiv werden. Die universale Supertopcheckerdatenbank für alles. :)

dergrieche
25.06.2012, 15:40
Stelle ich gerne rein, wenn es denn auch den Anforderungen entspricht :-)

Habe mir dein Suchkombination DB Code mal ausgedruckt und durchgestalked. Bevor ich dich also mit "wie funktioniert des" Fragen zubombe, erst ein paar Grundfragen vorweg, vllt ergeben sich dann ja schon Antworten.

Fragen:
- "Dim as" usw. steht für -> Definitionen? Du "aryCriteria" bist ein String -> was ist ein String?? dort wird also "vorweg" schon mal gesagt, wer was im folgenden Code als Aufgabe hat, korrekt?
- was ist "IngPersonID" Klar, -> die PersonID. wo kommt das Ing her?

Und bei mir ist des ja ein Endlosformular & nicht zu vergessen, dass ich eingrenzen muss von Props auf Stock (das is ja kein problem mehr).
- Was passiert, wenn der Anwender später eine neue property hinzufügt. Die steht ja nicht im "Code" und rein theoretisch könnte nach der neuen Property oder Stock oder was auch immer gar nicht gesucht werden? Kann man das dynamisch gestalten?


:-)

Atrus2711
26.06.2012, 08:37
"Dim as" usw. steht für -> Definitionen?
Ja. Mit Dim werden Variablen deklariert, d.h. ihr Name wird festgeschrieben und ihr Datentyp (Text, Zahl, Datum etc) umrissen. Das hat einen ähnlichen Zweck wie die Datentypwahl in Tabellen: wo ich eine Zahl erwarte, darf kein Text rein etc. Zusammen mit der unbedingt empfehlenswerten Option Explicit am Beginn aller Module ("Codedokumente") kann VBA dann auch auch Befehl gucken, ob die Deklarationen passen und ob unbekannte/vertippte Variablennamen benutzt wurden.

was ist ein String?
Eine Zeichenkette, d.h. ein Text. Dim strNachname as String deklariert die Variable strNachname als Text, d.h. sie kann alle möglichen Zeichen aufnehmen. Im konkreten Fall ist aryCriteria() allerdings nicht nur ein String, sondern ein Array (Stapel) von Strings, nämlich der Stapel der Einzelkriterien. Das erkennst du an den Klammern hinter dem Variablennamen und dem (atrus'schen) Präfix ary.

was ist "IngPersonID" Klar, -> die PersonID. wo kommt das Ing her?
Der ersten Buchstabe ist ein L (wie Long Integer), kein I. Das Voransetzen eines Typkürzels vor die Bezeichnung ist eine gängige Namenskonvention (klick! (http://www.donkarl.com?FAQ1.5)). Damit sieht man der Variable sofort an, was sie für einen Typ hat, und beim Tippen in VBA kann man nach Eintippen der ersten paar Zeichen alle passenden Begriffe mit Strg+Leerzeichen abrufen ("es muss eine Textvariable sein, also muss sie str... heißen" -> str eintippen, Strg+Leertaste -> Liste klappt auf).

Was passiert, wenn der Anwender später eine neue property hinzufügt
Die neue Prop ist lediglich ein neuer Datensatz in der Prop-Tabelle. Überall, wo du die Proptabelle in Formularen, Listenfeldern, Kombis etc. nutzt, wird die neue Prop automatisch erscheinen. Es muss eben nichts in Code "nachgezogen" werden. Du hast soeben den Clou des generischen Ansatzes erkannt. :birthday: Ich dachte allerdings, das sei bereits in #53 (http://www.ms-office-forum.de/forum/showpost.php?p=1453243&postcount=53) klargeworden....

Nochwas: es ist natürlich nicht schlimm, das alles nicht zu wissen. Aber dieses Wissen ist Handwerkszeug für die Programmierung von Access. Ohne diese Kenntnisse wird dir das Weiterentwickeln der Datenbank schwerfallen. Ein Forum kann dir bei einzelnen Problemen helfen, aber keine Ausbildung/Einarbeitung ersetzen. Das soll kein Standesdünkel sein (ich bin selbst auch kein Informatiker), aber sagen wir mal so: ohne Statikkenntnisse und Handwerkskunst kannst du kein Haus bauen..... und ohne Thermodynamik und Festigkeitslehre keine Motoren.

dergrieche
26.06.2012, 09:56
Die neue Prop ist lediglich ein neuer Datensatz in der Prop-Tabelle. Überall, wo du die Proptabelle in Formularen, Listenfeldern, Kombis etc. nutzt, wird die neue Prop automatisch erscheinen. Es muss eben nichts in Code "nachgezogen" werden. Du hast soeben den Clou des generischen Ansatzes erkannt. Ich dachte allerdings, das sei bereits in #53 klargeworden....

Natürlich ist mir das dort klar geworden und zwar Folgendes:
- immer wenn der Anwender eine neue Property braucht ist es nur ein neuer Datensatz, daher der Clou der generischen DB. Das hab ich schon verstanden. Ich wusste nur nicht, dass das im Code dann auch so einfach funktioniert. Da ich ja "im Suchformular" sage ich suche "Application" + "Radstand" + "was passiert bei neu?"
-> Anscheinend suche ich also nicht nach "Radstand" usw. sondern wie auch in deinem Beispiel nach "Nachname, hier: Property" -> Richtig/ Falsch?

Wie baue ich das Suchformular auf? Ich würde wie folgt rangehen:
- Ufo erstellen: Inhalt = Prop_description als cbo + stock_name als cbo (Eigenschaften + Vorräte)
- Die Vorräte werden auf die Eigenschaften eingegrentzt, sodass wenn der Anwender nun "Achse" auswählt, auch nur Achsen zur Auswahl stehen, usw.
- Wenn er das eingepflegt hat was er als Ausgang hat, muss ich in den "Suchen" Button den Code legen, ... -> da kann ich das von dir schon entworfene auf meine Anspürüche ummodeln?



Nochwas: es ist natürlich nicht schlimm, das alles nicht zu wissen. Aber dieses Wissen ist Handwerkszeug für die Programmierung von Access. Ohne diese Kenntnisse wird dir das Weiterentwickeln der Datenbank schwerfallen. Ein Forum kann dir bei einzelnen Problemen helfen, aber keine Ausbildung/Einarbeitung ersetzen. Das soll kein Standesdünkel sein (ich bin selbst auch kein Informatiker), aber sagen wir mal so: ohne Statikkenntnisse und Handwerkskunst kannst du kein Haus bauen..... und ohne Thermodynamik und Festigkeitslehre keine Motoren.

Da hast du natürlich vollkommen Recht. Ich hatte/ habe wirklich nur Grund Grund Grundkenntnisse von Access, die ich in der Oberstufe erworben habe. Da hatten wir null SQL, da hab ich mich selber eingearbeitet. Und VBA, da kennt man des eben nicht, aber wer lernen will und sich auch traut zu fragen, kriegt das hin.
Ich bin gerade Praktikant wie schon mal erwähnt und beginne dies Jahr mein Studium. Soll Elektrotechnik werden :-)

Atrus2711
26.06.2012, 10:26
Die Suche sollte so ablaufen:

Auswahl der zu untersuchenden Property (WO suchen) via Kombifeld.
Eingabe des gesuchten Wertes (WAS suche ich) in der gewählten Property. Wenn die Property einen Vorrat hat, kannst du per weiterem Kombifeld aus dem Vorrat auswählen: wo es hingegen beliebige Werte gibt, gibst du den gescuchten Wert einfach ein.
Evtl. (Luxus!) Auswahl eines Vergleichsoperators: WIE suchen? Gleich, kleiner, größer, Liste (2,3,4) etc. Machs erstmal mit Gleichheit.
Button, der dieses Einzelkriterium auf den Stapel legt und wieder leert, um das nächste Kriterium aufzunehmen.
Button, der das Gesamtkriterium zusammenbaut. Da hilft der Befehl BuildCriteria aus VBA und ein Blick in meine erwähnte Demo.
Anzeige der Treffer im Formular.


Wenn du hochlädst, kann ich auch versuchen, das aufzubauen. Es ist nicht ganz so einfach, wie es sich anhört.

Was den Code angeht: da du bei der Suche aus den vorhandenen Properties auswählst, gibt es keine "Neu-Problematik".

dergrieche
26.06.2012, 11:20
hier meine aktuelle DB

Könntest du das gewünschte Suchformular in das bestehende "frm_Structure_under_01" erstellen? Kannst dir den Rest natürlich ebenfalls gerne anschauen und mir deine Meinung dazu sagen.


Ich werde mich nun weiter um Output/ Berichte kümmern.



Danke :-)

EDIT: Anhang vergessen -.-

Atrus2711
26.06.2012, 12:22
Suchfunktion ist eingebaut in frm_Structure_under_01

Bedienung:

Property wählen
Gewünschten Propertywert wählen oder frei eintippen
"Stapeln"-Button anklicken.
Wiederholen für alle weiteren Kriterien (ggf. also auch gar nicht, wenn nur eine Bedingung benötigt wird)
Im grauen Fenster schreibt sich zur Illustration das Gesamtkriterium fort. Das ist nur für Lehrzwecke :)
Wenn alle Kriterien gestapelt sind, "Suchen"-Button anklicken. Es erscheinen die Fahrzeuge, die alle Einzelkriterien gleichzeitig erfüllen.
Reset-Button setzt die Suche (= Stapel und Gesamtkriterium) wieder auf "leer" zurück, so dass eine neue Suche beginnen kann.

Viel Spaß. Den rest hab ich mir nicht angesehen.

dergrieche
26.06.2012, 12:50
WOW !!! Danke, das ist richtig gut! Ich werde mich da reinarbeiten, damit ich das auch verstehe, was du mir hier bisher alles gelehrt hast. Und wenn die DB irnwann fertig sein sollte werde ich sie im Code-Archiv ablegen. Dann hat jeder was davon :-)

Atrus2711
26.06.2012, 12:57
Kannst mich ja als Coautor reinschreiben :grinange:

dergrieche
26.06.2012, 14:36
Mach ich! Des is ja wohl des mindeste :-)
Du hast mir ja nicht nur im VBA geholfen, sondern eigentlich bei allem unterstützt! Und was ich ganz toll finde: du hast mir die Sachen erklärt! Nicht einfach: hier nimm Ergebniss, sondern denk mal nach kleiner :-D

Nun hat sich bei mir die Frage ergeben, ob meine erstellte Hierarchie Sinn ergibt (im Formular für den Anwender) Über dein Suchformular wird mir ja jedes Fahrzeug angezeigt, was ich möchte.
Ich werde die Hierarchie Auswahl daher etwas optimieren und als Übersicht darstellen. durch ein cbo feld "kann" man filtern, wenn nicht, wird alles angezeigt. Wenn sein Fahrzeug nicht drin steht, muss er es erst anlegen.
-> Frage:
ich hab eine Liste. Diese Liste ist eine Darstellung der Zusammengeführten tblRange (frm_Structure/lst_range). Dort stehen also über die range_ID die Kombination des Type + Producer = Range. Nun möchte/ habe ich über der Liste ein cboFeld gelegt für den entsprechenden Eintrag. Ich möchte, zB. wenn im cboTYPE BUS ausgewählt wird, nur die Einträge mit Bus angezeigt werden.
Das habe ich auch rein theoretisch hingekriegt, indem ich der Datensatzherkunft dieses eine cboType zugewiesen habe und danach aktualisiere. Aber wenn ich nun über "optional zusätzlich" den Producer filtern will -> geht das auch über die Datensatzherkunft? Meiner Meinung nach nicht. Weil wenn ich in der Datensatzherkunft im Kriterium ein cboFeld angebe, prüft er den Eintrag ab. Wenn nichts drin steht, gibt er nix aus. logisch.

Stapler
Wer dann ein Fahrzeug sucht, geht über deine Suchmaske. Ich habe die Stapelfunktion auf "After Update" von dem zweiten cbo Feld gelegt (wertfeld). So muss der Anwender nicht immer extra Stapeln drücken. Wenn er nämlich nichts auswählt werden alle angezeigt (super!!!). Wenn er etwas auswählt, muss er ja sowieso auch einen Wert auswählen, also ist das Ereigniss After Update vom zweiten cbo obligatorisch und super geeignet für die Stapelfunktion (ne kleine Optimierung) :-)

Atrus2711
26.06.2012, 14:44
Über dein Suchformular wird mir ja jedes Fahrzeug angezeigt, was ich möchte.
Das war ja auch Sinn der Suche?! "Wenn es ein 3achsiges Bike (!) mit Schlafkabine gibt, und die Suche fragt danach, zeigs!". Kriegst du.

Dir ist nicht klar, dass die "Hierachie-Eintütung" eines Fahrzeugs in Type, Hersteller, Baureihe, Modell auch nur Eigenschaften sind. So wie es eine Eigenschaft "Achsanzahl" gibt, könnte es auch eine Eigenschaft Type geben.

Mir ist jetzt die Frage unklar....

dergrieche
26.06.2012, 14:54
Das war ja auch Sinn der Suche?! "Wenn es ein 3achsiges Bike (!) mit Schlafkabine gibt, und die Suche fragt danach, zeigs!". Kriegst du.

Genau. Das war ist und bleibt der Sinn. Das ist perfekt gelöst.


Dir ist nicht klar, dass die "Hierachie-Eintütung" eines Fahrzeugs in Type, Hersteller, Baureihe, Modell auch nur Eigenschaften sind. So wie es eine Eigenschaft "Achsanzahl" gibt, könnte es auch eine Eigenschaft Type geben.

Das ist ganz bestimmt machbar, aber das passt so schon :-)


Mir ist jetzt die Frage unklar....

-> Obs mein Wunsch trotzdem klappen tut wie es aktuell ist? :-)

Atrus2711
26.06.2012, 15:02
Und was ist dein Wunsch? :confused:

dergrieche
27.06.2012, 08:05
Schau dir des Screenchot an :-)

Atrus2711
27.06.2012, 11:49
Das ist doch dann eine Variante von http://www.donkarl.com?FAQ3.14:
"alle Sätze, die zum Kriterium passen oder (falls keins gewählt ist) alle Sätze".

Schema also (Luftcode):
Me.Listbox.Rowsource = "SELECT * FROM Quelle WHERE (Hersteller = cboHersteller OR cboHersteller IS NULL) AND (Modell = cboModell OR cboModell IS NULL) AND (usw).

ich hab die Demo "generics" übrigens hochgeladen. Und nein, es ist kein Code von dir drin. :)

dergrieche
27.06.2012, 13:30
Des mit dem Code probier ich sofort aus. Danke.
Haste hochgeladen? Coole Sache :-)

Unter was kann ich des finden?
Übrigens nehm ich die angebliche Verbessrung zurück von deienr Stapelfunktion. Ich hab nicht bedacht, dass wenn der Anwender sich mal "vertippt" also mal des falsche auswählt, geht er ja meist zurück in den Wert und wählt anstatt 4x2, den 6x4 aus. Dann würde aber der "Stapler" beides stapeln und das ergebniss wäre ja total sinnlos :-)

Daher nochmal, TOP! dein stapling ;-)

Atrus2711
27.06.2012, 13:38
guckst du in Codearchiv, ganz oben :)

Zum Stapeln: ich bin ohnehin ein Gegner von "voreiligen" Systemen. Solange das Suchkriterium nicht fertiggestellt ist, braucht die Suche nicht zu starten. Und der einzige, der erkennen kann, ob das Kriterium fertig ist, ist der Anwender. Soll er halt klicken. Halbfertige Treffer braucht keiner.

dergrieche
27.06.2012, 16:04
Hab mir deins mal angeschaut.
Funktioniert echt super gut! Hier eine wünschenswerte Änderung:

- im frmObjekteigenschaften. Dort fällt dem User als erstes natürlich das cboFeld auf. Er klickt drauf und wählt aus. Was aber wenn nichts drin steht? Klar, versucht es zu tippen -> Fehlermeldung erscheint, wird zu neuem frm weitergeleitet (das is ja noch halbwegs ok). Aber du hast nicht dran gedacht, wie der Anwender zB seine Motorleistungen ändern soll.
Das Feld Motorleistung ist zur Auswahl da. Aber wie ändert er die Eigenschaften? Da muss er (umständlicher weise) etwas in das cbo tippen, was es nicht gibt, damit er auf die Eigenschaften verwiesen wird, um dort zu ändern.
Im frmEigenschaften hingegen hast du das Problem super gelöst -> du hast n Button der den Anwender zu den Vorräten bringt. Wieso also auch nicht in den Objekteigenschaften? :-)


An sonsten ... wow echt genial! Ich werde mir davon gaaaanz viel abschauen.

EDIT: 2te wünschenswerte Sache
- Wenn in der Objektsuche "nichts" gefunden wird, sollte eine MsgBox dazu ihren Senf abgeben :-)

Atrus2711
28.06.2012, 09:28
- im frmObjekteigenschaften. Dort fällt dem User als erstes natürlich das cboFeld auf. Er klickt drauf und wählt aus. Was aber wenn nichts drin steht? Klar, versucht es zu tippen -> Fehlermeldung erscheint, wird zu neuem frm weitergeleitet (das is ja noch halbwegs ok). Aber du hast nicht dran gedacht, wie der Anwender zB seine Motorleistungen ändern soll.
Hab ich nicht verstanden. Lotse mich mal in dieses Problem.

Im frmEigenschaften hingegen hast du das Problem super gelöst -> du hast n Button der den Anwender zu den Vorräten bringt. Wieso also auch nicht in den Objekteigenschaften? :-)
Auich in den Objekteigenschaften kommt man zu den Vorräten. Klappe die Wert-Kombi auf (auch wenns noch leer ist), dort dann auf den Listedit-Button unten klicken, et voilá. Wenn du da lieber einen Button hättest, dann bau den ein. Abkupferbaren Code hab ich ja inzwischen genug drin.


- Wenn in der Objektsuche "nichts" gefunden wird, sollte eine MsgBox dazu ihren Senf abgeben :-)
Hier der Code dazu. Du weißt, wo er einzubauen ist.
If Me.sfmObjekte.Form.Recordset.RecordCount = 0 Then
MsgBox "Keine Treffer!"
End If

PS: Mein Motto sollte auch für dich gelten: "adopt, adapt, improve". Von request steht da nix.

dergrieche
28.06.2012, 10:22
Comprendes :-)