Office: (Office 2003) Diese Eigenschaft ist schreibgeschützt und kann daher nicht eingestellt werden!

Wenn ich die Datenherkunft vom Hauptformular "Eingabe" auf "Daten" (Tabelle) stelle, funktioniert das Kombinationsfeld mit der Abfrage wieder nicht.
Doch eine Anzahlberechung möchte ich unbedingt haben.

 

Ich würde dir gern einen Vorschlag machen, doch ich scheitere leider am Verständnis deines Datenmodells und dem Zweck deiner Anwendung.

Warum ist das Ufo über den Namen verknüpft, wenn dieser doch jeweils eine andere Bedeutung zu haben scheint: Nutzer A, Nutzer B, Ersatznutzer A, Ersatznutzer B? *confused.gif*

Auch weiß ich nicht, warum du die Datenherkunft des Kombifeldes mal nach "Betrag=2" und dann nach "abgeholt=True" filterst - das scheint mir recht willkürlich.

 

Das Ufo habe ich über den Namen verknüpft, damit ich abrufen kann, wie oft eine Person das Ticket in diesem Monat bereits genutzt hat. Ist das nicht richtig, oder kann ich es anders besser bzw. richtiger lösen?
Nutzer A, Nutzer B, Ersatznutzer A, Ersatznutzer B bedeutet: Wir haben 2 Tickets (das sind Monatstickets der Bahn) die für jeweils 2 Tage pro Monat zum Preis von € 2,00 ausgeliehen werden können. Sollte eine Person das Ticket bereits 2-mal im Monat genutzt haben, kann diese Person bei einer weiteren Reservierung nicht mehr automatisch das Ticket für sich belegen. Für diesen Zweck benötige ich die Ersatznutzer A und Ersatznutzer B, denn in diesem Fall wird diese Person unter Ersatznutzer eingetragen. D.h. Person A hat das Ticket bereits 2-mal genutzt und benötigt zB am 30.10.2008 das Ticket ein 3-mal. So wird Person A unter Ersatznutzer eingetragen. Nun kommt Person B, diese möchte das Ticket ebenso am 30.10.2008 und hat das Ticket in diesem Monat noch nicht bzw. erst einmal genutzt. In diesem Fall wird die Person B unter Nutzer eingetragen und Person B wird das Ticket bekommen und Person A erhält das Ticket nicht.

"Betrag=2" und "abgeholt=True" sind als Kriterien in der Abfrage eingetragen, denn mit „Betrag=2“ will ich erfragen, dass der Nutzer das Ticket bezahlt hat und mit „abgeholt=True“ möchte ich erfragen, dass die Person das Ticket abgeholt hat. D.h. ich will mit beiden Kriterien erfragen, dass das Ticket von dieser Person genutzt wurde. Das stimmt schon, ich würde bei Auswahl von anderen Kriterien zum selben Ziel kommen.

 

Ich bin der Meinung, dass dir die Schalter Nutzer-A, Nutzer-B, etc. gar nichts nutzen, wenn du nicht auch die Namen dazu im gleichen Datensatz hast. In diesem Fall würde ich fast sagen, dass die vier möglichen Nutzer in einen Datensatz geschrieben werden sollten und die Schalter sich dadurch erübrigen. So steht das alles auf wackeligen Beinen finde ich.

Wenn du es richtig machen willst, brauchst du zwei Tabellen: eine für das Ticket und eine zweite für die möglichen Nutzer.

Was deine Abfrage betrifft, so kann dadurch ein ziemliches Durcheinander entstehen, du hast doch (zumindest in besagtem Formular) überhaupt keinen Überblick, wer sich da schon alles drauf gemeldet hat. Die Beschränkung auf zwei Tickets pro Person ist die eine Sache, eine Beschränkung von Personen zum Ticket scheint mir nicht vorhanden. Dann hast du plötzlich zig "Bewerber" für ein Ticket: der eine hat nicht den erwarteten Betrag bezahlt (da reichte doch auch ein Häkchen, wenn es immer 2 Euro sind!), der andere noch nicht abgeholt etc. - wie willst du das in den Griff bekommen?

 

Na ja, wenn ich die 4 Nutzer in einem Datensatz geschrieben habe, brauche ich jedes Textfeld (Adresse, Tel-Nr.,..) 4-fach. Dann wird ein Datensatz ziemlich lange. Diese Möglichkeit habe ich schon mal programmiert gehabt und anschließend wieder verworfen.

Das stimmt schon, die Beschränkung auf die Person ist nicht vorhanden. Dies möchte ich mit der Abfrage über das Kombinationsfeld lösen, indem ich die Anzahl der Nutzung erhalte. Die Beschränkung, dass eine weitere Nutzung nicht möglich ist, weiß ich nicht zu programmieren. Dazu reichten meine Programmierkenntnisse leider nicht. Stimmt, es kann schon vorkommen, dass es viele Bewerber für ein Ticket gibt.
Das Ticket erhalten die Leute erst, wenn die € 2 bezahlt wurden. Daher stellt sich die Frage für uns gar nicht, dass eine Person den erwarteten Betrag nicht bezahlt hat bzw. der die andere Person das Ticket noch nicht abgeholt hat. Das ist für uns nicht das Problem.

 

Dann hast du recht, das kommt nicht in Frage.

Ich bin aber der Meinung, dass das berücksichtigt werden müsste, denn sonst hast du am Ende ein Problem, nämlich mit Datenmüll.

So gesehen würde ich dir raten, die Sache mit den zwei Tabellen anzugehen. Wie es jetzt ist, überzeugt es mich nicht, ist schwer händelbar, insbesondere mit geringen Programmierkenntnissen. *wink.gif*

 

Wenn ich 2 Tabellen mache (1 für die Nutzer und die zweite für die Tickets) wie kann ich dann die Abfrage der Anzahl der Monatsnutzungen für die jeweilige Person aufbauen?

 

Du kannst die beiden Tabellen in einer Abfrage verknüpfen und genauso auswerten als wäre es eine.

Kannst du mir noch etwas mehr über die Vergaberegeln erzählen, damit ich mir ein besseres Bild machen kann?
Wann z.B. darf der Ersatznutzer das Ticket abholen, d.h. wie lange muss gewartet werden, ob sich noch ein Erstnutzer meldet?
Und wie verhält es sich mit der B-Variante, wozu dient die?
Kann immer nur eine Person das Ticket nutzen oder gibt es auch Gruppentickets?
Geht die Reservierung stets für zwei Tage?
???

 

Der Ersatznutzer kann das Ticket haben, wenn sich bis zum Reisetag kein Erstnutzer meldet.
Nutzer B ist im Prinzip das Gleich wie Nutzer A, da wir 2 Karten haben. Die Person die zuerst anfragt, wird unter Nutzer A eingetragen. Ist die Karte A (Nutzer A) schon reserviert, wird die nächste Person unter Nutzer B eingetragen. Das läuft mit Ersatznutzer gleich, falls diese Person/Personen das Ticket bereits mehr als 2-mal ausgeliehen haben. Das Ticket kann nur eine Person. D.h. da wir 2 Tickets haben, können diese 2 Personen nutzen. Gruppen können dieses Ticket nicht nutzen. Diese beiden Tickets sind jeweils 1-Personen-Tickets. Die Reservierung kann auf 2 aufeinanderfolgenden Tagen gespeichert werden, aber dies muss nicht sein. Das Ticket kann auch an 2 unabhängig von einander stehenden Tagen reserviert werden (zB einmal braucht eine Person das Ticket am 03.10.2008 und einmal braucht die selbe Person das Ticket am 15.10.2008).

 

Im Grunde brauchst du doch für jeden Tag einen (vorgenerierten) Datensatz, dann kannst du schnell feststellen, welche Tage noch frei sind. Bei Buchung wird das das Reservierungsdatum eingetragen und der Status auf reserviert gesetzt. Das würde ich evtl. getrennt nach Ticket-A und Ticket-B machen. Die möglichen Nutzer (kann man die vorher festlegen, sozusagen eine Personaltabelle nutzen?) werden getrennt gespeichert und lediglich der Referenzkey wird als Nutzer-A/B etc. eingetragen.

Was hältst du davon? Ich glaube, so langsam kommen wir der Sache näher. *wink.gif*

 

D.h. es sollte für jeden Tag bereits ein Datensatz bestehen? Wie kann man ohne Dateneingabe bereits Datensätze vorgeben?
Die Liste der möglichen Nutzer kann man vorher nur schwer festlegen, da diese Liste ca. 2700 Personen umfassen würde und auch immer wieder wechseln kann.
Wie sollte so ein Referenzkey aussehen?

Stimmt, jetzt kommen wir der Sache näher und schaut nach einer vernünftigen Lösung aus. Jetzt heißt es, die ganzen Informationen in die Tat umzusehen und eine nützliche Datenbank erstellen.

 

Man kann die Datensätze mit einer Anfügeabfrage anlegen. Hilfreich könnte hierfür eine Datumstabelle sein, die sich leicht mit Excel erzeugen lässt: Anfangsdatum eintragen, markieren und runterziehen bis das Endedatum erreicht ist. Diese einspaltige Tabelle kann man in Access einbinden und die Anfügeabfrage damit füttern. Code:

Ein Referenzkey ist z.B. die Ident-Nr. (Autowert) der Nutzertabelle.

Ich habe mal ein wenig damit herum gespielt, da kannst du schonmal sehen, wie ich das gemeint habe. Krieg keinen Schreck, natürlich gibt es die Nutzertabelle nur einmal. Die wird nur wegen der Beziehungen mehrfach eingesetzt.

 

Danke für die netten Hilfestellungen!

Ich werde mich mal bemühen diese Informationen in die Tat umzusehen.

Warum werden bei dieser Variante mit den 2 Tabellen die Problem bei der Anzahlberechnung der Monatsnutzungen nicht mehr auftreten?

 

Das ist nicht der Grund für diese Struktur, sie soll helfen, die Ticketverwaltung transparenter und leichter handhabbar zu machen.

Es wäre schön, wenn sich noch andere an diesem Thread beteiligen und meine Theorie bestätigen oder ihr widersprechen würden... *sos

 

Wie kann ich dann die Anzahlberechnung der Monatsnutzungen am Besten lösen, so dass ich in der neuen Datenbank nicht die selben Probleme (Textfelder und Kombinationsfeld im Formular bzw. Unterforumar werden nicht angezeigt) wie in der derzeit noch aktuellen Datenbank?

Danke für die bereits länger andauernde Hilfestellung!