Hallo,
bin nicht sicher, ob ich das in das Forum Tabellen/Abfragen hätte machen müssen. Wenn dem so ist, dann muss ich den Admin bitten es umzuziehen.
Ich habe eine tblSpiele, welche unter anderem das Feld VarianteID_F beinhaltet. Darüber hat tblVariante eine n:1 Beziehung. Nun habe ich eine weitere Tabelle erstellt, tblVariantenArt, welche ebenfalls eine n:1 Beziehung hat, jedoch nur zur tblVariante. Im Erfassungsformular (welches auf der tblSpiele aufbaut), habe ich nun das Combifeld der tblVariantenArt neben dem Combifeld Variante eingebaut (siehe Bild2) und den Select entsprechend definiert (SQL-Code unten). Das Feld ist jedoch ungebunden (siehe Bild3), da ich im Steuerelementinhalt nur die Felder von tblSpiele angeboten bekomme. tblVariantenArt hat ja keine direkte Verbindung zur tblSpiele, sondern eben nur eine n:1 Beziehung über die tblVariante. tblVariante selbst ist über einen Fremdkey an tblSpiele angebunden (siehe Bild1). Deshalb bekomme ich das Combifeld wohl nicht gebunden :-(. Kann mir anhand der Angaben jemand Unterstützung zukommen lassen?
SELECT tblVariantenArt.VariantenArtID, tblVariantenArt.VariantenArt
FROM tblVariantenArt;
mfG
Andreas
Hallo,
ZitattblVariantenArt hat ja keine direkte Verbindung zur tblSpiele
Braucht sie ja auch nicht, wird ja über die Beziehung zu tblVariante dargestellt.
Zitat. tblVariante selbst ist über einen Fremdkey an tblSpiele angebunden (siehe Bild1). Deshalb bekomme ich das Combifeld wohl nicht gebunden
Doch, genau an dieses Feld (VarianteID_F) musst du das Kombi binden.
gruss ekkehard
Moin Ekkehard,
Zitat von: Beaker s.a. am Dezember 31, 2016, 01:29:10tblVariante selbst ist über einen Fremdkey an tblSpiele angebunden (siehe Bild1). Deshalb bekomme ich das Combifeld wohl nicht gebunden
Doch, genau an dieses Feld (VarianteID_F) musst du das Kombi binden.
Hmmm, das habe ich jetzt mal gemacht. Aber so wie das aussieht, habe ich ein anderes Problem und zwar mit meinem Verständnis :(. Ich habe in den Beziehungen noch einmal nachgeschaut, alle Beziehungen sind 1:n und nicht wie von mir beschrieben n:1. Die Tabelle tblVariante stellt über das Kombifeld lediglich die Werte A-H zur Auswahl (Bild1). In tblVariantenArt wollte ich nun auch über das Kombilfeld die ergänzenden Werte Deckblatt, Fehldruck, Spiel und Rückseite zur Auswahl anbieten (Bild2). Damit soll lediglich erreicht werden, wenn z.B. Spiel XYZ Variante B ist, ich es einer Variantenart zuzuweisen kann. Nachdem ich jetzt in tblVariantenArt als Steuerelementinhalt VarianteID_F eingestellt habe und ich z.B. im Formular Variante D auswähle, dann wählt er im Kombifeld Variantenart automatisch Rückseite aus. Also A=Deckblatt, B=Fehldruck, C=Spiel, D=Rückseite und E-H=bleibt leer. Das liegt ja wohl daran, dass ich als Steuerelemntinhalt eben VarianteID_F ausgewählt habe. Da macht er dann eine Feste Zuordung der Werte.
Ich wollte nun den Steuerelementinhalt abändern auf VariantenArtID. Dazu habe ich über den Ausdrucksgenerator folgendes hinterlegt
=[tblVariantenArt]![VariantenArtID] Da bekomme ich dann beim Auswählen eines Wertes im Kombifeld die Meldung
ZitatDas Steuerelement kann nicht bearbeitet werden;es ist an den Ausdruck ' =[tblVariantenArt]![VariantenArtID]' gebunden.
Wo liegt der Fehler?
Gruß Andreas
Hallo Andreas,
ZitatNachdem ich jetzt in tblVariantenArt als Steuerelementinhalt VarianteID_F eingestellt habe
Sorry, hätte deutlicher schreiben müssen; - nicht das Arten-Kombi sondern das
Variantenkombi muss an den Fremdschlüssel gebunden werden.
Ansonsten bin ich durch den Rest deiner Ausführungen ziemlich verwirrt. Kannst
du vielleicht eine Kurzversion deiner DB mit ein paar Beispieldaten hochladen?
Mir ist die Beziehung zwischen Varianten und -Arten irgendwie nicht klar; - vermute
da einen Trugschluss.
Falls es mit dem Hochladen nicht klappt, beantworte doch bitte diese Fragen:
Wodurch wird denn eine Variante überhaupt bestimmt? Es kann ja dem
Datenmodell nach für ein Spiel auch nur eine Variante geben.
Oder gibt es verschiedene Varianten von Deckblatt, Rückseite usw.? Dann wären
IMO aber die Varianten von der -Art abhängig, und nicht umgekehrt, und es gäbe
mehrere Varianten eines Spiels (n:m).
Habe allerdings auch das Gefühl hier (mal wieder) was zu übersehen oder falsch zu
interpretieren.
Vielleicht löst sich der Knoten mit o.a. Beispiel-DB von dir.
gruss ekkehard
Hallo,
wenn ich mich dann mal einmischen darf, ich kenne ja die DB glaube ich ziemlich genau, wenn ich mich recht erinnere. :D :P
Mir ist nicht ganz klar, wie das mit den Varianten zu verstehen ist.
Was ist die Variante und was die Variantenart (sind ja 2 Felder in 2 Tabellen), wie unterscheiden sich diese ?
Wenn das eine n:m Beziehung werden soll, ist die Beziehung falsch.
Erkläre daher erst mal die Zusammenhänge, ohne jetzt die DB direkt im Blick zu haben.
Hallo Klaus,
Zitatwenn ich mich dann mal einmischen darf
Aber gerne doch :)
Trotz Kenntnis scheinst du aber die gleichen Verständnisprobleme zu haben wie ich.
Da bin ich ja schon mal froh, nicht ganz auf dem Holzweg zu sein.
Dann warten wir mal ab, was da vom TS noch so kommt.
gruss ekkehard
P.S.: Guten Rutsch an alle.
Hallo Ekkehard und Klaus,
ich dachte es mir schon, dass meine Erklärungen nicht unbedingt Licht ins dunkel werfen werden. Mittlerweile bin ich unsicher, ob die tblVariantenArt nicht ebenso einen Fremdkey in der tblSpiele benötigt bzw. haben muss. Vielleicht noch als Hinweis zu Klaus, ich dachte man kann es lösen wie mit den Zusatzkarten. Da habe ich ein "ähnliches" Konstrukt. Ich versuche es mal genau zu beschreiben, da das hochladen ein wenig mehr Aufwand bedeuten würde.
Es gibt Spiele wie z.B. Nr. 647 von Ass. Das Spiel besteht aus 32 Spielkarten und dem Deckblatt, sowie eventuell Zusatzkarten wie Spielregeln und/oder Werbekarten etc. Nun kam es vor, dass der Verlag z.B. einen Fehldruck produzierte (z.B. Wertangaben innerhalb einer Spielkarte war astronomisch hoch etc.). Davon gab es sagen wir mal eine Marge von Spielen mit diesem Fehler, 500 Stück. Somit hatte man praktisch 2 Spielausführungen auf dem Markt, Variante A mit korrekten Angaben und Variante B mit den falschen Spielangaben. Also Variante A --> Varianten Art --> Korrekt und Variante B --> Fehldruck. Dann gab es z.B. Spiele mit Spielkartenrückseite in sagen wir mal der Farbe rot. Dann, warum auch immer haben sie eine Auflage mit den Kartenrückseiten mit der Farbe blau gemacht. Auch hier Variante A --> Varianten Art --> Korrekt und Variante B --> Varianten Art --> Rückseite. Das kannst du jetzt auch für Deckblätter oder Spieldate(n) fortführen. Ein Screenshot von tblVariantenart habe ich unten angehängt. Meint ihr auch, dass ich diese Tabelle mit einem FKey an tblSpiele anbinden ,muss, da e sich um spezifische Spieldaten handelt?
Gruß und guten Rutsch euch
Andreas
Hallo,
hast jetzt viel geschrieben, aber meine Frage nicht beantwortet:
ZitatWas ist die Variante und was die Variantenart (sind ja 2 Felder in 2 Tabellen), wie unterscheiden sich diese ?
Die Variantenart ist steht ja in einer Tabelle (tblVariantenart), das heißt die Varianatenart selbst ist ja ein Text der sich wiederholt, sonst wird ja keine Tabelle benötigt. Was schreibst Du dann in das Feld Variante der Tabelle "tblVariante" ?
Z.B. Variantenart: Fehldruck, Variante: Deckblatt Farbe rot
Hi,
nun ja, ich hatte ja im Thread schon erwähnt, dass es im Formular für die tblVariante auch ein Kombifeld gibt, was A-H zur Auswahl anbietet (siehe angehängtes Bild1 und Bild2). Ich schreibe also gar nichts, sondern wähle nur aus, so der Plan :). Hoffe die Frage ist damit beantwortet.
Gruß Andreas
Hallo,
hier liegt wieder eine klassische n:m Beziehung vor. Ein Spiel kann mehrere Variantenarten haben und eine Variantenart kann für mehrere Spiele zutreffen. Darstellung mit einem Unterformular. Beziehung siehe Bild.
Hi,
danke für die schnelle Antwort. Ohje, das sieht ja auf den 1. Blick nicht wirklich nett aus. Wie wirkt sich das aus, wenn ich das Feld VarianteID_F entferne und ist das nur über ein UFO zu realisieren? Da habe ich dann das Problem mit dem "Platz" im Erfassungsformular. :(, da muss ich mal schauen wie und ob ich das so einbaue. Schei..
Gruß Andreas
Zitat von: MzKlMu am Dezember 31, 2016, 16:30:59
Hallo,
hier liegt wieder eine klassische n:m Beziehung vor. Ein Spiel kann mehrere Variantenarten haben und eine Variantenart kann für mehrere Spiele zutreffen. Darstellung mit einem Unterformular. Beziehung siehe Bild.
Hi Klaus,
ich hab mir jetzt mal eine Kopie der aktuellen DB erstellt und angefangen hin und herzuschieben, damit ich das UFo eingebaut bekomme. Ich habe dann alles gemäß deinen Angaben mal ein/umgebaut. Aktuell sieht das mit den Beziehungen aus wie im Bild1. Im Formular sieht das aus wie in Bild2.
Die Abfragen, Code zum Feld Variante:
SELECT tblVariante.VarianteID, tblVariante.Variante
FROM tblVariante
ORDER BY tblVariante.VarianteID;Code zum Feld Variantenart:
SELECT tblVariantenArt.VariantenArtID, tblVariantenArt.VariantenArt
FROM tblVariantenArt;Scheint alles zu funktionieren wie es soll. Danke für die Hinweise und das Anleiten.
Gruß Andreas
Hallo Klaus,
ich habe mich wohl doch zu früh gefreut. Ich habe jetzt gesehen, dass wenn ich eine Variante definiere es 2 Einträge in der DB gibt. Wenn ich die Variantenart auswähle, z.B. STD.-Ausgabe oder Deckblatt etc., dann übernimmt er das. Aber gleichzeitig legt er auch in der tblVariante einen neue Variante an und zwar ist die Nummer die ID des Datensatzes aus tblVariantenart, siehe Bild1-3. An den Abfragen (siehe#11) scheint es ja wohl nicht zu liegen, sonst könnte ich ja nichts auswählen. Liegt es an der Art der Beziehung? Eine Auffälligkeit ist, wenn ich nur die Variante auswähle ohne anschließend die Variantenart anzugeben, dann meckert er (siehe Bild4). Wo habe ich jetzt schon wieder den Fehler eingebaut?
Gruß Andreas
Hallo Andreas,
hast Du das Ufo über die Schlüsselfelder (SpielID > SpielID_F) auch verknüpft ?
Unabhängig davon irritiert mich die Verwendung von 2 Kombis. Für die Variantenart ist das klar, da steht eine Tabelle dahinter, aber für die Variante ist das unlogisch. Die Variante ist ja gemäß der Tabelle Freitext und kein Kandidat für eine Tabelle und demnach kann das eigentlich kein Kombi sein.
Daher noch mal die Frage, was ist der Unterschied zwischen Variante und Variantenart ? Das habe ich immer noch nicht richtig verstanden.
Hallo Klaus,
danke der schnellen Nachfrage. Ich denke, die Erklärung in Beitrag #2 im Thread ist immer noch voll umfänglich und erklärt es richtig.
Vor dem Umbau, war das Feld Variante auch ein Kombi, es war noch nie ein Freitextfeld. In der Tabelle sind die Werte A-H hinterlegt. In Bild1-2 siehst du wie es vor dem "Umbau" war. Da habe ich dann lediglich ausgewählt ob es sich bei dem Spiel um Variante A, B, C ...... etc. handelte, sofern das bekannt war.
Aber daraus stellte sich dann immer öfter die Frage, um welche Variante handelt es sich denn überhaupt, Fehldruck, Deckblatt, Rückseite oder Spieldaten Variante?? In der Vergangenheit hatte ich mir dann immer eine Notiz im Freitextfeld Informationen gemacht. Dann habe ich eben gedacht, man müsste einfach ein weiteres Feld generieren, welches einen die Variantenart definieren lässt. Das ist eigentlich schon alles, was ich dazu noch sagen kann :(.
Gruß Andreas
Hallo,
bitte bedenke, dass ich immer noch von der Materie keine Ahnung habe und daher mehrfach nachfragen muss, ich muss es ja verstenden haben, wenn ich Dir was raten soll.
Aber jetzt habe ich es glaube ich verstanden.
Zu einem Spiel kann es mehrere Variantenarten geben und zu einer dieser Art wiederum einen der Buchstaben A - H (Variante), ist diese Annahme richtig ?
Hallo Klaus,
kein Problem, das ist selbst mir manchmal erst beim 2 oder 3 mal hinschauen erst so richtig bewusst, wie sich das verhält. :(.
Ja, das ist meines Erachtens korrekt verstanden. Ein Spiel, kann unter Umständen mehrere Varianten haben, welche dann durch die Varianten Art spezifiziert werden können (Fehldruck, Deckblatt, Rückseite etc.). Die Varianten selbst unterscheidet man dann meiner Meinung nach am besten durch A,B,C etc.
Ich frage mich gerade, ob ich nicht gleich das ganze so anlegen muss/sollte, wie du mich beim Thema Identische Kartensätze angeleitet hast http://www.access-o-mania.de/forum/index.php?topic=21968.0 (http://www.access-o-mania.de/forum/index.php?topic=21968.0). Da könnte ich dann praktisch mit einem Endlosformular auch die anderen Varianten gleich mit aufführen. Ich stelle die Frage deshalb, weil mir der Gedanke vorhin beim spazieren gehen mit dem Hund in den Kopf geschossen kam und diese Variante ja noch einmal deutlich komplexer wäre, oder?
Gruß Andreas
Hallo,
dann müssen wir umbauen. Es wird noch eine Tabelle benötigt für die Verknüpfung der Variantenart mit der Variante (z.B. "tblVariArtVari") mit folgenden Feldern:
VariArtVariID (PS)
SpielID_F
VariantenArtID_F
VarianteID_F
Wie zu verknüpfen ist, ergibt sich durch die _F.
Das Ufo erhält diese neue Tabelle als Datenquelle und je ein Kombi zur Auswahl von Variantenart und Variante (über die Fremdschlüssel). Ufo über die SpieleId verknüpfen. Am Formularaufbau selbst musst Du nichts ändern.
Zeige bitte noch mal ein Beziehungsbild wenn Du das gemacht hast, nur um sicher zu gehen. :D
Für mich stellt sich aber die Frage, brauchst Du diese Buchstaben überhaupt ?
Durch die Art hast Du doch eine klare Unterscheidung, wozu dann noch ein Buchstabe?
Nebenbei:
Zitatbeim spazieren gehen mit dem Hund
Was hast Du denn für einen Hund ?
Ich habe zwar keinen, bin aber großer Hundefreund, bzw. die ganze Familie. Meine Tochter engagiert sich schon mehrere Jahre im Wormser Tierheim
jedes Wochenende mehrere Stunden zum Gassi gehen mit den dortigen Hunden, bei Wind und Wetter. Ihr zolle ich da großen Respekt.
Hi,
dann lass mich mal kurz zusammenfassen. Anschließend haben wir 3 Tabellen.
tblVariante --> VarianteID (PS), VariantenArtID_F, SpielID_F, Variante
tblVariante --> VariantenArtID (PS), VariantenArt
tblVariArtVari --> VariArtVariID (PS), SpielID_F, VariantenArtID_F, VariantenID_F
Beziehungen würden dann so aussehen wie in Bild1. Ich will es einfach mit Buchstaben versehen, weil es in der Sammlergemeinde einfach Usus ist :). Man redet diesbezüglich praktisch in Buchstaben :). Mit dem vollständigen umsetzen warte ich jetzt erst mal, ob die Basis so i.O. ist.
Wir haben einen Malteser Bichon Frise, 12 Jahre alt. Ja, wenn jemand sich so für Lebewesen engagiert, dann fordert es einem tiefen Respekt ab.
Gruß und danke vorab
Andreas
Hallo,
das hast Du zu kompliziert gemacht. Siehe Bild.
Bitte ändere und zeige es noch mal.
Hi,
ich hatte im Beitrag vorher schon geschrieben, dass mir diese beiden suspekt vorkommen, eben weil doppelt gemoppelt, habe das aber wieder aus Unsicherheit gelöscht :(. Hab es angepasst, schaus dir an in Bild1.
Gruß Andreas
Hallo,
ja, so sollte das passen. Musst jetzt nur das Ufo anpassen, das enthält ja nur die 3 Schlüsselfelder. SpielID_F für die Ufo Verknüpfung und die anderen beiden für die Kombis.
Hi,
jo irgendwie habe ich leider noch einen Fehler. Schau dir mal bitte die 5 Bilder an, welche ich angehängt habe.
Zu Bild2 wirst du sicher fragen, was hinter der qrySpielIDSpielNrVari steckt. Hier der SQL Code dazu
SELECT tblSpiele.SpielID, tblSpiele.SpielNr, tblSpiele.Ausgabejahr
FROM tblSpiele;
Das wollte ich ja genauso haben wie es im frmErfassungUfoIdentQuartette ist. Beispiel:
Spiel-ID 495, welches korrekt ist, ist die Variante A --> Variantenart STD-Ausgabe. Dann will ich ja gleich die Variante mit angeben, also Spiel-ID 496, Variante B --> Variantenart Deckblatt. So war der Plan.
Wenn ich jetzt die Spiel-ID auswähle, dann macht er das erst mal noch, aber sobald ich dann die Variante wähle, z.B. A, dann springt die ID wieder auf 1 zurück. Muss ich da wieder mit einer Kopie der tblSpiele arbeiten, siehe Bild6?
Gruß Andreas
Hallo,
Du denkst zu kompliziert. Das Kombi für das Spiel ist ersatzlos überflüssig. Die SpielID_F wird über die Verknüpfung Hafo/Ufo automatisch gefüllt, mit der ID des im Hafo angezeigten Spiels. Die Verknüpfung hast Du ja angelegt. Also Kombi löschen. Die beiden anderen Kombis sind richtig. Die in Bild6 rot eingetragen Beziehung ist nicht notwendig. Ich hatte das schon mal so geschrieben:
ZitatDas Ufo erhält diese neue Tabelle als Datenquelle und je ein Kombi zur Auswahl von Variantenart und Variante (über die Fremdschlüssel). Ufo über die SpieleId verknüpfen.
Also nur 2 Kombis.
Noch was zu Gestaltung. Den Löschbutton zum Löschen einer Variante würde ich so nicht machen. Du musst ja aufpassen, dass der zu löschende Datensatz den Fokus hat, sonst löschst Du einen falschen Datensatz. Ich würde in den Detailbereich einen kleinen Button (mit einem roten X) anlegen, der sich dann für jeden Datensatz wiederholt. So bist Du sicher, dass der richtige DS gelöscht wird. Und den Platz für den Fuß des Ufos hast Du auch gespart und kannst so auch 2-3 Varianten direkt anzeigen.
Moin,
ich denke mal was das komplizierte denken angeht, das ist unheilbar :-[.
Ich dachte eben, dass ich jetzt im Datensatz ID 495 (um beim Beispiel zu bleiben), auch gleich hinterlegen kann, welche ID in der Datenbank die Variante B oder C hat! Dazu hätte ich ja dann die Beziehung mit der zur zusätzlichen tblSpiele benötigt. Das kann ich so ja nicht, was kein Problem ist, aber das war eben der Hintergedanke bei dem zusätzlichen ID Feld.
Ich hab umgebaut, also die unnötige Beziehung gelöscht, das ID-Kombi gelöscht, den delete Button in den Detailbereich verlegt und somit auch den Formularfuß ausblenden können. Das passt jetzt wenn ich eine Variante anlege (Bild1). Ich kann natürlich auch jetzt Variante B, C etc. da anlegen, man sieht dass es Varianten gibt, aber ich weiss eben nicht welche ID die Variante in der DB hat und muss somit suchen. Du verstehst was ich meine?
Gruß Andreas
Hallo,
beschreibe das bitte noch mal und verwende mal die vollständigen Namen für die IDs, auch bei den Fremdschlüsseln, ich bin da ganz durcheinander. :D
Hi,
ne du bist nicht durcheinander, das ist eben wie wir gestern gesagt haben meist doch komplexer wie man meint.
Nehmen wir doch mal an, ich habe 1 Spiel, das ich in 3 Ausführungen habe. Die Standard Ausgabe ohne Fehler, dann gibt es eine mit anderer Rückseite und eine, welche falsche Spieldaten hat. Wenn sie vor dir liegen würden, wären sie auf den ersten Blick identisch! Jetzt wollte ich folgendes erreichen. Ich bin in DS-ID 495 (der Standard Ausgabe ohne Fehler), definiere da im UFO Variante A --> Variantenart STD-Ausgabe (STD ist normierter Ausdruck für Standard :P). Dann kann ich im UFO auch Variante B (DS-ID 817) --> Variantenart Rückseite und Variante C (DS-ID 953) --> Variantenart Spielkarte(n) mit angeben. Wenn ich das so mache, denkt man, dass dieses Spiel 3 Varianten hat, aber wo und welche ist die Variante im aktuellen DS-ID 495, oder DS-ID 817 oder DS-ID 953? Dazu müsste ichjetzt wieder das Info Freitextfeld bemühen und mit Hinweisen das ganze aufklären. Variante B und C auch im DS-ID 495 anzulegen macht nur dann Sinn, wenn man auch die ID des Varianten-Spieles in der DB mitgeben kann bzw. sieht (darauf verlinken was auch immer). Das war der große ganze Plan :). Ich hoffe, es war ein wenig klarer was ich meine.
Gruß Andreas
Hallo Andreas,
ZitatWenn ich das so mache, denkt man, dass dieses Spiel 3 Varianten hat,
Ist doch auch so gewollt, oder haben wir da noch was völlig falsch verstanden?
Zitataber wo und welche ist die Variante im aktuellen DS-ID 495, oder DS-ID 817 oder DS-ID 953?
Die brauchst du doch gar nicht mehr, ein(e) Spiel/-variante wird doch jetzt durch
den PK (VariArtVariID) der Tabelle "tblVariArtVari" eindeutig bestimmt.
Wenn du jede Variante als einzelnes Spiel (DS) anlegen willst, würde da dann ja auch
ein FK zur Tabelle "Varianten" ausreichen. Die zusammen gehörigen Varianten
müssten dann über eine n:m-Beziehung der tblSpiele mit sich selbst dar zu stellen sein.
@Klaus
Bitte korrigiere mich, falls ich Andreas' letzten Post falsch interpretiere.
gruss ekkehard
Hallo,
ZitatBitte korrigiere mich, falls ich Andreas' letzten Post falsch interpretiere.
ich habe es ja immer noch nicht so recht verstanden.
@Andreas
Wenn Du von ID spricht (DS-ID 495, oder DS-ID 817 oder DS-ID 953?) ist das die SpielID ?
Wenn ja, habe ich wie gesagt immer noch Verständnisprobleme.
Ein Spiel hat Variantenarten die wiederum in Buchstaben eingeteilt werden, das ist doch richtig oder ?
Sind diese Varianten auch als eigenständiges Spiel erfasst ?
Hallo Klaus,
ZitatSind diese Varianten auch als eigenständiges Spiel erfasst ?
Auf dieser Annahme beruht meine Antwort.
gruss ekkehard
Hi Ekkehard und Klaus,
ZitatWenn Du von ID spricht (DS-ID 495, oder DS-ID 817 oder DS-ID 953?) ist das die SpielID ?
Wenn ja, habe ich wie gesagt immer noch Verständnisprobleme.
Ja, DS=Datensatz, sorry wegen der Abkürzung. Also ID 495, 817 und 953 sind Spiel-ID's
ZitatEin Spiel hat Variantenarten die wiederum in Buchstaben eingeteilt werden, das ist doch richtig oder ?
Sind diese Varianten auch als eigenständiges Spiel erfasst ?
Ja genau. Ich habe ja geschrieben ....
Zitat...... ich habe 1 Spiel, das ich in 3 Ausführungen habe. Die Standard Ausgabe ohne Fehler, dann gibt es eine Ausgabe mit anderer Rückseite und eine Ausgabe, welche falsche Spieldaten hat. Wenn die 3 vor dir liegen würden, wären sie für dich auf den ersten Blick identisch!
In der Datenbank sind alle 3 Spiele erfasst. Die Datenbank bildet meine Bestand komplett ab, nicht nur logisch!
Gruß Andreas
Hallo Andreas,
ZitatIn der Datenbank sind alle 3 Spiele erfasst. Die Datenbank bildet meine Bestand komplett ab, nicht nur logisch!
Das ist aber doch redundant. Und wenn du dann noch bei jedem varianten Spiel
auch alle Varianten speichern willst doch eh. Da kannst du die Variante doch gleich
direkt beim Spiel angeben, siehe
ZitatWenn du jede Variante als einzelnes Spiel (DS) anlegen willst, würde da dann ja auch
ein FK zur Tabelle "Varianten" ausreichen.
gruss ekkehard
Hallo Ekkehard,
Redundanz hin oder her, alles gut. Was aber bitte schön ist denn so verkehrt daran, sich im UFO auch die ID der Varianten B oder C anzeigen zu lassen, damit man weiss, welche ID die Variante B oder C in der DB hat? Wir reden ja von 1000 en Datensätzen die ich dann in der DB "manuell" nach den beiden Varianten durchsuchen müsste, nicht nur 150. Versteh ich es nur nicht, oder habe ich es euch immer noch nicht richtig erklärt?
Ich will ja nur das Feld ID mit im UFO der Varianten haben, dann sehe ich nicht nur, dass es Variante B oder C gibt, sondern sehe auch gleich, aha, die Variante B hat die Datensatz ID 817. Dann kann ich gleich dort hin springen ohne groß zu suchen oder was auch immer. Alles in allem ist es einfach nur eine Erleichterung, mehr nicht.
Gruß Andreas
Hallo Andreas,
ZitatWas aber bitte schön ist denn so verkehrt daran, sich im UFO auch die ID der Varianten B oder C anzeigen zu lassen, damit man weiss, welche ID die Variante B oder C in der DB hat?
Im Prinzip nichts, nur brauchst du die ja gar nicht mehr. Die Varianten eines Spiels
werden doch in einem UFO (DS-Herkunft = tblVariArtVari) automatisch angezeigt
wenn das HFo/UFo über die SpielID verknüpft ist.
ZitatIch will ja nur das Feld ID mit im UFO der Varianten haben
Wo liegt da das Problem? Wenn die SpielID in der DS-Herkunft des UFo vorhanden
ist kannst du doch auch ein Textfeld anlegen, das daran gebunden ist.
gruss ekkehard
Hi,
ZitatWo liegt da das Problem? Wenn die SpielID in der DS-Herkunft des UFo vorhanden
ist kannst du doch auch ein Textfeld anlegen, das daran gebunden ist.
gruss ekkehard
#22, da hatte ich es ja schon gemacht, jedoch noch mit Fehler. Dann kam die Anweisung, mach weg das Zeugs, unnötig. Das lag wohl daran, dass es nicht "richtig" gelesen oder von mir erklärt wurde. Okay, ich muss ja auch nicht immer Folge leisten, habe mich da jedoch erst mal auf die Expertise verlassen (bitte festhalten, das ist alles Vorwurfsfrei!!).
Fazit, so weit war ich ja schon, aber bekam eben den Fehler nicht gelöst.
Ich bau es noch mal um, dann schauen wir mal, was die Uhr so anzeigt.
Gruß Andreas
Hallo,
ich wollte euch noch einmal direkt fragen, ob man das mit dem Thema ID mit angeben nicht so lösen kann, wie man das auch mit den identischen Kartenspielen schon gemacht hat. Ihr werdet jetzt sagen, ja dann mach doch, aber ich laufe eben in einen Fehler :(. Beim Thema Identische Kartenspiele war der Lösungsansatz so wie in Bild1-3. Bild1 ist die qryIdentQuartett, Bild 2 im UFO, wo ich nur die ID heraussuchen kann (völlig unabhängig von der ID des aktuellen Datensatzes), dann befüllt er die Felder wie gewünscht (Bild3). Für das Feld ID in Bild2 ist noch eine qrySpielIDSpielNr hinterlegt (Bild4). Nun habe ich eine qryfrmVariArtVari erstellt (Bild5, die kann so aber nicht funktionieren :(..) und für das ID Feld die qrySpielIDSpielNrVari (Bild6).
Klaus wird sagen ich denke mal wieder zu kompliziert, weil es wahrscheinlich nur eine Kleinigkeit ist, damit es geht. Was ist in der Abfrage falsch?
Gruß Andreas
Hallo Andreas,
Bastele gerade an einem Beispiel; - ist praktischer.
An einer Frage hänge ich jedoch im Moment.
Sind die Buchstaben (Varianten) den Arten immer fest zugeordnet?
Also A = Standard, B = Deckblatt, C = Rückseite usw. ?
Das würde die Sache vereinfachen da man dann nicht zwei Tabelle brauchen
würde. Und wenn das so wäre, wäre auch mein Beispiel fertig (fast).
gruss ekkehard
Hallo Ekkehard,
ZitatSind die Buchstaben (Varianten) den Arten immer fest zugeordnet?
Also A = Standard, B = Deckblatt, C = Rückseite usw. ?
Das würde die Sache vereinfachen da man dann nicht zwei Tabelle brauchen
würde. Und wenn das so wäre, wäre auch mein Beispiel fertig (fast).
gruss ekkehard
Hmmm, die Frage ist ja gar nicht dumm. Zuerst dachte ich mir sofort, nee muss frei bleiben ist doch klar. Aber ja, A sollte doch immer die STD-Ausgabe sein. Aber A ist auch das einzige, was ich fix machen könnte/wollte. Insofern, würde ich es "frei" lassen und nicht fest zuordnen.
Ich habe auch noch mal gebastelt, bekomme es aber nicht hin, dass Daten eingetragen werden. Dabei habe ich mich immer noch an dem Beispiel des frmErfassungUfoIdentQuartette orientiert. Aber nah dran ist auch vorbei :(.
Gruß Andreas
Hallo,
Hier das Beispiel.
Im HFo werden Variante (A, B, ...) und Art (Standard usw.) per Lookup angezeigt.
Im UFo werden die Varianten über die SpielID ausgewählt. Durch die Redundanz
musst du da allerdings für jede Variante alle anderen Varianten auch anlegen.
Ob alles so wie gewünscht bzw. richtig ist bin ich mir allerdings leider nicht so sicher.
gruss ekkehard
Hallo Ekkehard,
erst mal danke für die viele Mühe. Einzig ein Thema ist dabei, was wir gestern angesprochen haben, was so nicht passt. Einzig A wäre prädestiniert dazu, eine fest Zuordnung zur Variante A zu haben, alle anderen müssten offen "frei" von Zuordnung bleiben. Ergo, keine Zuordnung. Von daher ist das das einzige, was "nicht passt". Das bedeutet ja, dass man 2 Tabellen nehmen müsste, sprich Variante und Variantenart trennen, oder? Ansonsten basiert es voll und ganz auf dem Grundgedanken den ich hatte.
Gruß Andreas
Hallo Andreas,
ZitatEinzig A wäre prädestiniert dazu, eine fest Zuordnung zur Variante A zu haben, alle anderen müssten offen "frei" von Zuordnung bleiben. Ergo, keine Zuordnung
Das widerspricht aber früheren Aussagen:
ZitatAlso A=Deckblatt, B=Fehldruck, C=Spiel, D=Rückseite und E-H=bleibt leer.
???
gruss ekkehard
Hi,
tut es das?
Beitrag #38
ZitatHmmm, die Frage ist ja gar nicht dumm. Zuerst dachte ich mir sofort, nee muss frei bleiben ist doch klar. Aber ja, A sollte doch immer die STD-Ausgabe sein. Aber A ist auch das einzige, was ich fix machen könnte/wollte. Insofern, würde ich es "frei" lassen und nicht fest zuordnen.
Aber, ich müsste ja "nur" der Definition folgen. Insofern muss ich mal schauen, ob ich damit klar komme.
Gruß Andreas