So... Ich hab mir mal jetzt den Quellcode genauer angeschaut... Erstmal ist da ein Logikfehler: getDaysOfMonth(Monat,Year(Now())) ist falsch, da immer das aktuelle Jahr genommen wird. Wenn aber der Februar ins nächste Jahr fällt, kann da die Tagesanzahl falsch berechnet werden.
Hubert hat recht... Du machst das alles unnötig kompliziert und Fehleranfällig. Z.B. Funktioniert Dein Code auf einem englischen Server nicht mehr. Ansonsten scheint Deinem Code nur die Möglichkeit zu fehlen mit mehreren Kontingenten umzugehn. Leider schreibst Du nicht welche an welche Bedingungen sich Deine Daten halten. Für mich sieht das so aus, als ob Du ein wenig blauäugig ans Datenformat rangegangen bist. Denn wenn Deine geplante Tabelle so aussieht... Kontingente: date_from, date_to, room_count ... ist das vielleicht für die Ausgabe gut zu gebrauchen, aber zur Verwaltung von Resourcen ist das völlig ungeeignet. 3 Zimmer sind also frei... Welche? Bei dennen , die an diesem Datum nicht frei sind... Warum nicht? Wer hat die gebucht? Was ist, wenn eines dieser Räume plötzlich nicht mehr 6 Tage gebraucht wird, sondern nur noch 3? Dann müsste aus einem Datensatz plötzlich zwei werden... Dieses und vieles andere kann obige Datenstruktur nicht oder nur sehr kompliziert abbilden. Normalerweise geht man auch davon aus, dass eine Resource immer frei ist und man speichert Ausnahmen(Buchungen) davon und nicht umgekehrt immer belegt und Freizeiten speichern. Ich nehme auch an, dass nicht alle Resourcen gleichwertig sind. Wenn also irgendjemand zwei Sääle braucht, dann bekommt er doch bestimmt zwei bestimmte Sääle reserviert und es wird nicht nur vermerkt, dass er zwei Säle hat und beim Termin darf er sich dann zwei aus den freien auswählen... Also erzähl bitte etwas mehr über Deine Anforderungen, dann bekommen wir zusammen auch ne gescheite Datenstruktur hin, die das abbildet und die Ausgabe kommt dann auch noch früh genug... Ein paar Gedanken zur Datenstruktur: - Gehen wir mal davon aus, dass jede Resource jeden Tag belegbar ist und die kleinste Belegungs-Granularität ist ein Tag, d.h. es kann nicht einer die Resource einen halben Tag belegen und ein anderer den Rest des Tages. Wenn das bei Dir anders ist, muss die Datenstruktur angepasst werden. Mögliche DB-Struktur: Resource(id, name, kuerzel, typ, ....) Belegung(id, resourcenID, startDatum, endDatum, kommentar, ...) Das ist sehr vereinfacht. Normalerweise hat man auch noch mind. ne Tabelle für die "Kunden", die die Resourcen belegen usw. Genaueres wenn Du Deine Anforderungen erklärst Wie Du siehst kann man hier jetzt besser die Buchungen verwalten, aber das Ausgeben des Kalenders wird komplizierter... Du solltest Dir auch überlegen, ob die Anzeige so wie Du sie jetzt hast wirklich was bringt. Angenommen es gibt drei grosse Säle und vier kleine Zimmer. Ich will jetzt für kommendes Wochenende zwei Säle buchen. Was genau bringt es mir wenn ich an dem Tag eine "3" lese? Ich hab keine Ahnung, ob diese drei Resourcen Säle enthalten oder nicht - die Ansicht ist höchstens brauchbar um zu sehen ob man ausgebucht ist. Wenn nicht, kannst Du aber keine Aussage darüber treffen ob benötigte Resource noch vorhanden ist. Neben den Anforderungen an der Datenstruktur solltest Du Dir also auch Gedanken drüber machen welche UseCases es gibt, also welche Interaktionen es mit dem System gibt und wie diese ablaufen, z.B. "Resource buchen", "Freies Resourcen-Kontingent suchen" etc... So... Jetzt bist Du dran. Gruss, Claudius _______________________________________________ Coffeehouse Mailingliste, Postings senden an: [email protected] An-/Abmeldung und Suchfunktion unter: http://www.glengamoi.com/mailman/listinfo/coffeehouse
