Office: (Office 2007) Optionsgruppe Abfrage

Ja wie, wird der Button 'Schuh anzeigen' denn nicht sichtbar, wenn alle rot markierten Optionen gewählt werden?
Dann sorry!
Nachvollziehen kann ich das aber nicht, bei mir geht's.

In dem Fall setze den Button im Entwurf auf 'Sichtbar: Ja' und lösche die Sub SchuhButtonZeigen - auch in den AfterUpdate-Ereignissen der Optionsgruppen.

 

Guten morgen tahjiun,

zu Punkt1) es war die Situation gegeben, dass alle roten Punkte markiert sein müssen

zu Punkt2) wenn alle roten markiert sind, dann wird der Button sichtbar (funktioniert einwandfrei)

zu Punkt3) schau dir mal die Abfrage (SchuhErgebnisAbf) an, dann sollte sich dieser Punkt auch klären

Gruß
Sören

 

Habe das Beispiel noch etwas erweitert.
Nun kann man anhand der Abfrage 'SchuhGrpAlleAbf' auch im Klartext sehen, welche Eigenschaften jedem Schuh zugeordnet sind.

 

Auch falls es den Themenstarter nicht mehr interessiert, ich selbst fand's ganz reizvoll, weshalb jetzt auch die Artikel- (in dem Fall Laufschuhe) und Zuordnungstabelle normalisiert ist (und somit auch auf die UNION-Abfrage und andere Krücken verzichtet werden kann).
(Wobei man allerdings übrigens zur Auswahl von Kriterien mit Optionsgruppen lang nicht so flexibel ist, wie z.B. mit Kombifeldern.)

 

Ist ja ne richtig schöne Bsp. DB geworden *biggrin.gif*

Ich Frage mich nur, ob tahjiun sein Problem schon gelöst hat?

PS: Dein letzter Satz mit den Kombifeldern ist Gold Wert, ist wesentlich komfortabler und platzsparender! *top

 

Das mit den Kombifeldern hätt' ich dir auch so sagen können. *Smilie
Aber freut mich, dass es insofern doch was gebracht hat. *biggrin.gif*

 

Natürlich bleibe ich noch dran!!
Habe mir die letzte Tag die Beispiel grundlich durchgegangen. Zugegeben, dass man innerhalb weniger Tagen die Programmiersprache nicht meistern kann, aber ich gebe mir Mühe!

Erstmal zu den Kommentäre von SHeyer:
1) Logisch habe ichh ALLE rote punkt markiert. Ist immer noch so, dass bei alle erte Bsp Prog kein 'Schuhanzeige' Button rauspoppt, aber selbst das kann man einfach lösen, wie KHS im vorherige Betrag beschrieben hat.

@KHS:
Nochmals Herzlichen Dank fürs Bsp. Programm, vor allem die 2. Da ist mir klar geworden, wie es funktionieren soll. Wie Statistik und Wahrscheinlichkeitsrechnung, wenn ich richtig verstanden habe.

Allerdings läuft das 2. Bsp Prog. bei mir immer noch nicht. Nachdem ich die Optionen mit der rote Punkte ausgewählt habe und auf Schuhfinden klicke, passiert nichts.

Vermisse ich da etwas?

PS:Werde jetzt die neueste Bsp Prog vom KHS reinziehen.

Merci.

 

Hallo allerseits,

Ich habe versucht ein Beispiel im Stil vom der 3. DB vomn KHS zu erstellen, und bin auf folgende Probleme gestossen:

1) Bei der TWHZuordAnsichtAbf Abfrage bleiben die Zeilen und Reihen, die zu der Abfrage OptionenAbf_TWH gehören, leer anstatt die richtige Beziehung.
Woran liegt das Problem?

2) Bei anklicken der Abfrage 'OptionenAbf_TWH' springt immer das Fenster auf mit der Anforderung ' OptionsgruppeTbl_TWH.GrpID_TWH2', man sollte etwas eingeben. Habe ich was falsch definiert, so dass die Fenster rausspringt?

2.1) Ebenfalls springt das Fenster 2 mal auf beim anklicken von 'TWHZuordAnsichtAbf', und wenn man 'Cancel' klickt, ergibt ein Tabelle mit leere Inhalt...warum?

3) KHS hat mit Absicht 'SchuhID' in 'SchuheTbl' und 'Schuh_ID' in 'SchuheZuordnungenTbl' den ID anders genannt, mit welchem Zweck?

Bin für jeder Ruckmeldung bzgl. die Probleme dankbar!!

 

Hallo tahjiun,

könntest du die Test DB in das alte Format (.mdb) abspeichern? Ich denke mal, dass dir dann mehr Leute helfen könnten, da nicht jeder Access07 hat und somit die DB nicht öffnen kann.

Gruß
Sören

 

Alles klar, hier nochmals die Datei.

Bitte um zügige Kommetare / Hilfe!

@KHS: Können Sie schonmal die Begründung für Frage 3 reinposten?

 

So, ich glaube, dass ich die Lösung zu Punkt 1, 2 und 2.1 habe.

In deiner Abfrage "OptionenAbf_TWH" beziehst du dich in der ersten Spalte (Entwurfsansicht) auf einer Tabellenspalte welche nicht existiert.

Code:

ersetze den Teil durch:

Code:

dann sollte es funktionieren.

Gruß
Sören

 

Zu Punkt 3) (Schuh_ID vs. SchuhID) wage ich zu behaupten, dass das keine Absicht war. *wink.gif*

Wenn man den Primärschlüssel vom Fremdschlüssel unterscheiden will, bzw. den Fremdschlüssel als solchen kenntlich machen, könnte ich mir folgende Konvention als sinnvoll vorstellen: Code:

 

\@SHeyer: Gute Auge, Sören. Danke!


@anne: Mag wieder ein doofer Frage sein, aber warum die Unterscheidung zwischen die Primärschlüssel und Fremdschlüssel?
Da ich hatte davon ausgegangen, dass um die Eigenschaften von 2 Tabellen zusammenzubinden, sollte dann die Bezeichnung gleich sein, damit die zusammenhang auch identifiziert werden kann.

 

Ich wollte nur einen Denkanstoß geben, einen möglichen Weg zeigen. Im Grunde bin ich aber durchaus der Meinung, dass gleiche Bezeichnungen ihre Vorteile haben. Hauptsache ist, dass man sein persönliches Konzept möglichst systematisch und konsequent umsetzt.

 

Zitat Anne:
"...möglichst systematisch und konsequent..."
Und da bin ich zugegebenermaßen etwas - sagen wir mal - 'flexibel'! *wink.gif*

In diesem - 'mit heißer Nadel gestricktem' - Fall hab ich das eben spontan zur einfacheren Unterscheidung im Bedarfsfall gemacht.
Das ist kein 'Gesetz'!
Neulich gab's zu dem Thema 'Feldnamen' auch hier einen Beitrag (UNTERSTRICHE NACH S UND Z LÖSCHEN!):
Code: