Office: (Office 2010) Formular Textfelder aktualisieren nicht

Hm, ich beginne zu verstehen. Aber eins ist mir noch unklar:

Als Konfigurator bist du doch der, der aus den überhaupt denkbaren Kombinationen eine Kombination "zum Leben erweckt". Da kommt dann ein Object raus, z.B. die neue Actrus-Linie von Perpedes-Renz, die bestimmte Eigenschaften hat (Leistung, max. Achslast, etc). Deine Rolle wäre also die des "Perpedes-Chefs", der dann zu seinen Ingenieuren sagt: baut mir das!

Aber du wählst in deiner DB aus Vorhandenem aus. Als Konfigurator schaffst du doch neues. Das, was es schon gibt, ist doch nur für einen Selektor relevant. Denn der schafft nix Neues, sondern sucht das Passende.

Was also bist du?

 

Das Produktmanagemend hat natürlich schon seine genauen Vorstellungen welche Kombinationen gewünscht sind und welche nicht. Die brauchen aber ein Verwaltungstool/ Planungstool. Der Konfigurator ist ein Mittel zum Zweck, Entschuldigung, falls ich mich undeutlich ausgedrückt habe.

Meine direkte Rolle ist lediglich das Tool zu erstellen. Ingenieur werd ich noch, dauert noch ein bisschen.

Alle vorgegebenen Kombinationen die aus dem Portfolio herausgehen, werden in dieser DB enthalten sein. Dann fragst du dich, wieso auch mehrere Unternehmen -> weil wir Kooperationen mit anderen haben, die ggf. auch bei uns aus "Interesse" abgebildet werden.

Ab jetzt nenne ich es Selektor :-)
(bin essen) bis gleich

ps: Percedes-Renz .... genial, den merk ich mir :-D

 

Eine völlig leere Datenbank ließe sich damit aber dann nicth füllen, denn dann gibts nichts zu wählen und nicht auszuwählen...?

 

Hier mal ein Ansatz. Es ist recht viel Code, aber es sieht so aus wie dein Ansatz. Das Anlegen neuer Sätze geht erstmal nur durch den Button Neu, der einen leeren (!) Satz anlegt, und anschl. bearbeiten dieses Satzes. Unschön, aber durch die Sperren erstmal so gewollt.

Mit einem Formular, das jeweils eine Stufe "pflegt", könnte das aber auch fast ohne Code gehen. Dafür sieht es dann ein bisschen anders aus.

 

Hi,

danke für deine TestDB.
Bei mir erstellt er aber keinen neuen "leeren" datensatz, sondern kopiert den, den ich angeklickt habe. Den kann ich dann aber natürlich im textfeld bearbeiten. Ist auf jedenfall eine Variante, aber kann zu Fehlern und Dopplungen führen? Bike darf nur einmal drin stehen.

Ich hab mir wegen deiner Aussage da noch mal gedanken zu gemacht. Du hast Recht, dem Anwender ist es im Endeffekt egal, wie das Problem gelöst wird. Eben noch mal meine Betreuerin gefragt "nach ihrer Anwendersicht". Es ist für den Anwender (wie du schon sagstest), besser über ein Pflegeformular zu arbeiten. Ich würde die txtFelder "locken" damit nichts geändert werden kann. Immer wenn was geändert, neu oder geölscht werden soll, soll der entsprechende Button geklickt werden -> Pop-Up/ neues Formular und dort soll des gemacht werden, auch der Vorteil, dass der Anwender jede seiner Tätigkeiten bestätigen muss, reduziert die Fehlerquote.


*korrektur:
wenn ich das formular neu öffne und alles noch grau ist, dann auf NEU klicke, ist es ein leerer datensatz.
wenn ich aber mich vorher durchgeklickt habe, dann auf neu gehe, kopiert er den datensatz :-)

 

So ist es. Der Button Neu speichert die aktuellen Textfeldinhalte als neuen Satz ab. Aber wenn die Textfelder noch gesperrt sind, kann man da natürlich noch nichts eingeben. Dann wird bisher halt ein Satz mit leeren Textfeldern gespeichert, der dann aber existiert und somit angeklickt und bearbeitet werden kann. Ein doppeltes Bike kann entstehen, wenn du den existierenden Bikesatz mit Neu erneut anlegst.

Schön ist das nicht. Aber ich hätte auch so nicht angefangen *biggrin.gif*

Das ist aber Sache des Datenmodells. Da würde ich auf die Bezeichnungen einen eindeutigen Index setzen, dann wird ein zweites Bike abgelehnt. Derm Formular darf/muss das egal sein.

Ja, das ist der übliche Weg. Der geht quasi ohne Code über die Eigenschaft "Bearbeitungsformular für Listenelemente". Da trägst du den Namen des Forms ein, das die jeweils relevante Tabelle (Type, Make, Range) pflegt. Diese Formulare sollten dann natürlich auch existieren *wink.gif*

 

ich hab eben gerade mal wieder einen absturz meiner DB gehabt.
ich hab lediglich zwei drei neue formulare erstellt und über vba den Befehl zur Öffnung des Formulares erstellt. auf einmal schließt sich meine DB einfach, nur weil ich ein element schließen will, oder ins VBA will -.-
sogar, wenn ich im frm_Selector auf das erste Listenfeld klicke, schließt sie sich auch!

=> WIESO???

zum glück hatte ich ne _sik datei :-D


Ich habe die DB nun etwas erweitert, schaue sie dir einfach mal an.
In der tblType, hab ich das txtFeld type_name auf indiziert ohne Duplikate gesetzt, dann vermeidet er die Doppeleinträge -> logisch. Aber bei tblMake und tblRange kann ich das nicht so machen, da dort ja "Doppeleinträge" erlaubt sein sollen. Truck oder Bus ... dort bewegt sich zB Percedes-Renz ja auch. deswegen muss ja in dem Feld zwei mal percedes-Renz stehen.

Wenn nun in dem frm_Selector die vorauswahl der Kombis gemacht wurde, steht der nächste Button zur Verfügung, der den Anwender zum direkten Autoselektor führt. Dort weiß ich ejtzt nicht genau, wie ich folgendes problem lösen kann. Wenn du dir die Tabellenstrukturanschaust, merkst du, dass durch die generik in der DB, die eigentlichen Trägertabellen nun Datensätze sind, also sind die Eigenschaften nun die Textfelder. Was mache ich, wenn ein Fahrzeug "optionen" haben soll?

Z.B. Truck hat unterschiedliche Federungen, die zur Auswahl im Selektor vorliegen sollen für den Anwender. Ich hab da schon einige Sachen drin stehen, schau es dir einfach mal an. Einige Bemerkungen habe ich ebenfalls in der DB.

 

Hi,

ist ein netzwerk im Spiel? Access ist ziemlich empfindlich gegen Netzwerkausfälle, auch kurzzeitige. Da krachts gerne mal.
Ansonsten sind Abstürze so aus der Ferne schwer zu begründen... *eek.gif* Importier mal alles in eine neue DB, das klärt manchmal interne Verschränkungen.

Die DB schau ich mir an.

 

Hi,

ein indizierter Index kann auch mehrere Felder umfassen. Beim Hersteller ist der Firmennamen (ein Feld) sicher das einzige Indexfeld, denn es gibt nur einen Hersteller namens Perpedes-Renz.

Bei den Modellen hingegen ist es anders. Gängiges Beispiel: es gibt den Ford Focus, aber es spricht kein Naturgesetz dagegen, dass Peugeot morgen auch einen Focus rausbringt. Der Modellname alleine ist also nicht eindeutig, wohl aber Modell und Hersteller gemeinsam.

Was die Optionen angeht, steck ich nicht tief genug in der Fahrezugentwicklung. Deine generische Db soll ja die eingestellten Werte für die möglichen Größen aufnehmen. M.E. kann nur ein Object (= Fahrzeug) eingestellte Werte haben:Länge = 18,20 m, Gewicht=32 t, Tankinhalt= 400 l. Aber die hierarchische Eingliederung des Objects (in Type/Make/Range) könnte die möglichen Größen beeinflussen. Mal naiv gedacht: wenn es ein Bus ist, muss es eine Eigenschaft geben wie "Anzahl Passagiersitzplätze". Wenn es ein Truck ist, ist diese Eigenschaft irrelevant, dafür gibt es bei Trucks z.B. die Aussage "Ruhekabine j/n". Heißt: für alles, was Bus ist, wird die Passagieranzahl als mögliche Größe eingerichtet und für ein Bus-Object auch verlangt; für ein Truck-Object wird stattdessen die Ruhekabine erfragt.

Es müsste also irgendwo festgehalten sein, welche (gegliederte) "Fahrzeugklasse" zu welchen möglichen Eigenschaften führt. Diese möglichen Eigenschaften werden dann für ein Object erfragt und mit konkreten Werten belegt.

Im Anhang mal ein Beispiel, wie ich das mal gelöst habe. Da ging es um Details zu KFZ-Verträgen wie Haftpflichtversicherung, Leasing, Finanzierung, Garantien etc. Eine Haftpflichtvers. hat z.B. die Eigenschaft Deckungsumme, aber eine Finanzierung hat andere Eigenschaften. Je nach Vertrasgart werden im Ufo dann die relevanten Eigenschaften erfragt.

 

Hi Atrus,

ich hoffe du kannst mir erneut weiter helfen.
Ich habe mir deine Screenshots angeschaut, finde ich gut!
Weiß aber nicht, ob ich das so bei mir machen kann? Begründung im weiteren Verlauf.

Ich habe mir nun gedacht, da es Fahrzeuge schon gibt, dass ich einen SELECTOR anlege, der dann den Output liefert. Für die Fahrzeuge die erst noch eingetragen werden müssen, habe ich dann einen CONFIGURATOR.
Um Type, Make und Range zu pflegen habe ich mich nun für die Pflegeformulare entschieden.

Ich hab jetzt aber ein Problem mit der Umsetzung der SELECTOR/ CONFIGURATOR. Wie kann ich nun, da ich ggf. mehrere Optionen für eine Eigenschaft habe, das korrekt darstellen?
Wenn ich zB Tires (Räder) -> ein Fahrzeug kann unterschiedliche Bereifung bekommen, daher stehen meist 2 - 3 unterschiedliche reifen zur Verfügung. Diese stehen bei mir aktuell in EINEM Datensatz. Wenn ich für jeden Reifen einen neuen Datensatz erstelle, ... nun ja ... das ist nicht zielführend. Dann müsste ich ja für "alles" mehrere Datensätze erstellen. Wie löse ich des Problem?

Wie gesagt, kann man aus einem Datensatz über bestimmte Codes es ermöglichen mehrere Optionen in einem Datensatz zu speichern -> Gegenfrage: ergibt das Sinn? Man muss ja auch imemr die Vor- und Nachteile im Blick behalten.


Die kaputte DB ... funktioniert wieder -.-
Leider etwas zu spät, denn ich habe schon alles in eine neue Importiert und weitergearbeitet. Woran das liegt, weiß ich nicht. Es ist mir schon paar mal passiert, dass sie abgeschmiert ist. Aber die hat dann auch nie wieder funktioniert. ist ja jetzt auch egal, hauptsache des neue läuft ^^


Ich habe gerade versucht die DB anzuhänge, aber sie ist zu groß?? Die Größe der DB beträgt 545 KB -.-


Eintrag bearbeitet: Anhang hinzugefügt:
DB funktioniert wieder nicht -.-
Klicke im ersten Formular auf den button, und die DB schmiert einfach ab. Die LOG datei bleibt erhalten, da das Programm nicht korrekt schließt -.-
Die SicherunsDB hat jetzt auch das gleiche problem, obwohl die 5 Minuten vorher angelegt wurde!

 

Wenn das Object aufgrund seiner Einordnung in Type, Make und Range Reifen "zu haben hat", dann sind in meiner bisherigen Denke die möglichen Werte dafür "frei", d.h es gibt da keinen Wertvorrat. Wenn du da einen haben willst, brauchst du die möglichen Werte für eine Eigenschaft lediglich in einer neuen Detailtabelle abzulegen: Eigenschaften 1:n Eigenschaftenvorrat. Da stehen dann z.B. für die Eigenschaft Reifen die möglichen Reifendimensionen als Sätze drin. Aus diesen Werte kannst du dann auswählen, z.B. per Kombifeld. In meinen Bildern wären das dann also Kombifelder bei den eingestellten Geldbeträgen für Deckungssumme, Selbstbeteiligung etc.

Die DB guck ich mir an. Edit: bei mir läuft sie...

 

Das ist echt eigenartig *frown.gif*
Woran kann das liegen, dass sie bei dir läuft und bei mir nicht? Die "alte" geht bei mir wieder, die neue die vor 10 Minuten noch einwandfrei funktioniert hat, schmiert ab. Das kann doch nicht wahr sein -.-

Das mit der Detailtabelle hab ich noch nicht ganz verstanden. ich fass das mal in meinen Worten zusammen, wie ich des bisher verstanden hab.

Ich erstelle eine Tabelle "die eine Detailstufe höher" ist als die Eigenschaften, weil die Eigenschaften (Properties) ja ziemlich allgemein gefasst sind. Aber stehen denn nicht in der Value schon die "Details" also die genauen Spezifikationen des Fahrzeuges drin?
Der Eigenschaftenvorrat ist also eine Tabelle, in der jetzt nur Reifen drin stehen? Nein, das wäre ja nicht im Sinne einer generischen DB. Der Eigenschaftenvorrat ist also eine Tabelle die an die Value angeknüft wird, in der ich den FK der Eigenschaftsvorrat Tabelle einfüge, damit dem Arugment "Reifen" mehrere Optionen angefügt werden können. Richtig? Dort stehen dann wieder Reifen, bunt gemischt mit Federungen untereinander in einer Tabelle, was aber egal ist, da sie über ihren PK, dem gezielten Reifen in der Value zugeschrieben sind.
-> Oder muss ich mit properties verknüpfen? Das wäre doch unlogisch. Da stehen doch lediglich die Allgemeinen Bezeichnungen der in der Value verknüpften Datein.

richtig oder falsch? :-)

 

Bleiben wir bei den Reifen. Angenommen, es gebe überhaupt (in der gesamten Datenbank) folgende Reifentypen:

1. 195/40 R17
2. 195/40 R19
3. 185/40 R 15

dann sind das die möglichen Werte für die Values, das ist schon richtig. Da es aber vermutlich nicht für alle Values Vorräte gibt (einige könnten echte Freitexte sein), würde ich die Values nicht als Fremdschlüssel-Verweis auf die Vorratswerte aufbauen, sondern die Klartextwerte des gewählten Satzes übergeben. Ein eingesetzter 195/40 R17 wird also mit diesem Wert 195/40 R17 in die Values kopiert, nicht mit seiner Kennziffer 1.

Das ist denormalisiert. Aber mit Absicht. Der Vorrat erleichtert lediglich die Eingabe der oftmals (aber eben nicht immer) gleichen Werte. Aber es ist halt nicht verboten, auch listfremde Werte einzutragen. Der Vorrat ist also nur eine Tipphilfe, keine strikte Einschränkung.

Access findet Wege *Smilie Hast du mal neu importiert, komprimiert und retestet?

 

Genau. Nicht jede Value hat Vorräte, richtig. Bleiben wir wie du sagstest bei den drei Reifen. AAA (jetzt hats klick gemacht, ... glaub ich)
Vorweg:
Bedeutet Freitext, dass der Anwender den neuen Reifen vorher lediglich über ein freies Textfeld hinzugefügt hat?!

Wenn ich nun im Selector meinen Truck suche und dann zur Auswahl die drei Reifen habe, ich mich für den 195/40 R17 entscheide, ... wird doch lediglich aus der Eigenschaftsvorratstabelle der Wert entnommen der in beziehung zum Allgemeinen "Reifen" steht? Anders erlaubt mir meine Logik gerade nicht zu denken -.-
Der Wert muss ja irgendwo her kommen, er muss ja auch gepflegt werden können. -> Frage: werden also diese Werte allgemein angelegt und man kann drauf zugreifen oder nicht, wenn man will -> logische Schlussfolgerung sagt, die Vorratstabelle muss an die Properties, ok - verstanden. Und in der Value steht dann der Text, die Bezeichnung, welcher aus der Vorratstabelle der Eigenschaften ausgewählt wurde. Das ergibt natürlich wieder Sinn :-)

Gegenfrage: (da hats noch nicht klick gemacht)
Wird also jeder einzelne Truck mit jeder einzelnen Möglichkeit neu angelegt?
Zum Beispiel: ich wähle einen Truck, der hat - wie schon gesagt - drei unterschiedliche reifen zur Auswahl. Werden dann drei angelegt?, wegen den drei Reifen? Das wäre ja nicht zielführend. Es soll ja ein einziger Truck sein, der halt mit drei Reifen genutzt werden könnte. Man muss ja bedenken, dass es noch mehr als nur Reifen gibt, in denen es "Optionen" geben wird. Das heißt, wenn mehrere abgespeichert werden, dass exponentiell viele Trucks angelegt werden -> nicht erwünscht.


Edit:Habe alles bis auf die Formulare in dene bisher VBA genutzt wird importieren können. Wenn ich versuche auch nur ein einziges Formular mit VBA zu übernehmen, schließen sich die DBs wieder und die LOG bleibt bei beiden offen.

 

Freitext heißt: man tippt Beliebiges ein. Der Nachname von Personen ist z.B. ein typischer Freitext: da gibts keinen Vorrat, die Leute heißen, wie sie heißen.

Nein. Weil dein momentanes Object ein Truck ist, "hat" es grundsätzlich Reifen zu haben. Welche und wieviele davon, ist dann in den Values abgelegt. Für die Reifen (bei allen Objects!) gibt es Vorräte, denn egal ob es ein Truck, Bus oder Gabelstapler ist: alles was Reifen hat, kann sich nur aus den verfügbaren Reifengrößen bedienen.

Mal ein anderes Beispiel zur Illustration: du bist ein Versandhandel und willst Eigenschaften der Artikel abbilden. Jacken haben dabei eine Farbe und ein Material, Thermoskannen haben nur eine Füllmenge, Bücher haben einen Autor und ein Erscheinungsjahr. Bei den Farben könnte es meinetwegen eine Auswahl geben (rot, blau, grün) und bei den Füllmengen ebenfalls (500, 750, 1000 ml). Diese Vorgaben bilden - aus Sicht der Objektorientierung - Klassen. Aber die Klasse Jacke kann man nicht anziehen, und die Klasse Thermoskanne nimmt keinen Tropfen Kaffee auf. Nur Objekte - konkrete, "angewendete" Klassen - können das. Und bei dieser Anwendung (=Produktion) müssen die geforderten Eigenschaften mit Werten belegt werden. Die Thermoskanne steht nur im Lexikon, aber die auf dem Tisch hat eine Füllmenge von 750ml. Da die Klasse Thermoskanne keine Farbe erfordert, gibts keine Farbe anzugeben. Auch ein Autor ist der Thermoskanne fremd, weil sie kein Buch ist.

"Wer hat was zu haben" ist also die Struktur. Beim Erzeugen ist dann zu ergänzen: "und in welcher Ausprägung".