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

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.

 

und

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

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.

 

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.

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?!

 

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.

 

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.

 

Wenns fertig ist, könnte das dein Erstling im Codearchiv werden. Die universale Supertopcheckerdatenbank für alles. *Smilie

 

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?


:-)

 

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.

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.

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

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

 

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?

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

 

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

 

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

 

Suchfunktion ist eingebaut in frm_Structure_under_01

Bedienung:

1. Property wählen
2. Gewünschten Propertywert wählen oder frei eintippen
3. "Stapeln"-Button anklicken.
4. Wiederholen für alle weiteren Kriterien (ggf. also auch gar nicht, wenn nur eine Bedingung benötigt wird)
5. Im grauen Fenster schreibt sich zur Illustration das Gesamtkriterium fort. Das ist nur für Lehrzwecke *Smilie
6. Wenn alle Kriterien gestapelt sind, "Suchen"-Button anklicken. Es erscheinen die Fahrzeuge, die alle Einzelkriterien gleichzeitig erfüllen.
7. 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.

 

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

 

Kannst mich ja als Coautor reinschreiben *grinangel

 

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