Verhuursysteem probleem en vraag

[spgoos]

Ben naar mijn idee al een heel eind op weg maar nu loop ik vast

 

Ben bezig voor de jeugdvereniging waarbij ik zit een systeempje in elkaar te boksen als vervanger van een vreselijk irritant excelbestand voor het bijhouden van de contracten/facturen van de tenten die wij verhuren (voor het bekostigen van onderhoud en vervanging).

 

Eerst even de achtergrond van de opzet:

 

Aan een contract wordt een (contact)persoon toegevoegd uit de tabel personen. Indien er namens een andere vereniging een tent wordt gehuurd dan kan er organisatie uit de tabel organisaties worden toegevoegd.

 

Vanuit de layout van de contracten kan er een layout worden geopend met de beschikbare artikelen (zijn dus tenten en vuurtonnen). Via een aantal hulpvelden in de tabel beschikbaar komen de geselecteerde artikelen in de tabel contract_artikelen.

 

Op zich werkt het nu allemaal, maar ik ben bezig aan de hand van dit voorbeeld van NightWing Enterprises het zo te krijgen dat de reeds verhuurde artikelen niet meer te selecteren zijn. Hier ligt het probleem... volgens mij heb ik alles zo correct mogelijk nagebouwd maar ik blijf de reeds verhuurde artikelen zien in de keuzelijst

 

Heeft iemand een idee hoe ik het wel aan de praat kan krijgen? Volgens mij zit het hem alleen in het feit dat ik geen waardes krijg in het veld beschikbaar::ckey_nietBeschikbareArtikelen - maar ik kan het ook fout hebben.

 

Verder alvast een vraag: hoe kan ik zeg een maandoverzicht maken met daarin aangegeven welke artikelen verhuurd zijn op een dag?

verhuur_v020.fp7

[Koen Van Hulle]

Het probleem is dat je relatie tussen beschikbaarheid en contracten_artikelen vanuit beschikbaarheid niet geldig is.

 

De sleutels ckey_huurstart en ckey_huurEinde zijn niet geindexeerd (unstored calculatie) waardoor de waardelijst "nietBeschikbareArtikelen" leeg blijft.

 

Dit heb ik opgelost door de tabel contracten hier tussen te plaatsen en de calculaties ckey_huurstart en ckey_huurEinde te verplaatsen naar contracten, waardoor de waardelijst wel juist word gevuld.

 

Ik vind dit persoonlijk een erg complexe oplossing voor het probleem en bij veel artikelen zou het wel eens erg traag kunnen worden. Als ik tijd heb werk ik wel een vereenvoudigde oplossing uit.

 

 

Koen

verhuur_v021.fp7

[spgoos]

Thnx!! Ik ga er even naar kijken hoe je het hebt gefixed.

[spgoos]

Eigenlijk is het wel logisch om die ckey_huurStart en ckeyhuurEinde in de tabel contracten te zetten. Had ik eerder ook al geprobeerd maar ik ben er toen niet niet opgekomen om een hulptabel in de relaties toe te voegen - had ik het maar want dat had me een halve dag klooien gescheeld.

 

Ik heb ondertussen de scripts iets "gedebugged" zodat deze inderdaad de toegevoegde artikelen niet meer tonen nadat je er een hebt toegevoegd.

 

Verder had ik ook al bedacht dat dit een redelijk trage manier kan zijn als het groter wordt, maar dat voorbeeld van NightWing was eigenlijk het enige goede voorbeeld dat ik kon vinden om als uitgangspunt te nemen... Aan de andere kant valt het toch wel mee met die performance kwestie als er niet meer artikelen zijn dan - zeg - 30 of 40 stuks, of niet? Daarmee heb ik dan alle tenten en vuurtonnen van het moment mee gedekt en mogelijk toekomstige extra's, zeker als je in beschouwing neemt dat een tent op een gegeven ogenblik vervangen wordt en daarbij gewoon hetzelfde artikel in de database zal blijven. Dit zullen er niet veel zijn aangezien het hok van de werkgroep Tent nu al uit zijn voegen barst, haha.

 

Weet iemand waar ik een voorbeeld kan vinden met betrekking tot het maken van een soort van kalenderoverzicht met daarop de gehuurde artikelen per dag? (Of in ieder geval schopjes de goede richting in; deze zijn natuurlijk ook welkom.)

Het gaat niet zozeer om bij welk contract deze horen, maar meer als een grafische weergave van welke artikelen reeds bezet zijn op een dag als we bij de telefoon staan...

[WJ]

Beste spgoos,

 

Hier zit je waarschijnlijk niet op te wachten maar ja, kan het niet laten.

 

Je wilt allerlei functies wat ik goed kan begrijpen, maar je gaat te snel.

 

Ik zou eerst eens even alles wat je hebt netjes maken, voordat je het weet heb je een brei waar je niet meer uitkomt. Moeten er ook andere mensen met je systeem werken ? Zorg dat er een beetje lijn in je programma komt. Bouw een interface als je in het begin een interface bouwt dan kan je schermen layouts dupliceren en her gebruiken. Als je eerst alles maakt en dan schermen gaat ontwikkelen zal dit je veel meer tijd kosten. De puntjes op die i zoals bovenstaande besproken functie zou ik op het allerlaatst doen eerst de basis neerzetten.

 

Groet,

 

WJ

[spgoos]

Nee hoor, alle opmerkingen zijn altijd welkom!! Ben momenteel inderdaad bezig met de layoutkant van het verhaal netjes in orde te maken voordat ik het verder ga uitbreiden - maar ik ben wel benieuwd naar hoe ik de vervolgstappen kan uitbouwen

 

Er zullen naar alle waarschijnlijkheid maar 2 en maximaal 3 personen (3e zal dan alleen met een gast-account zaken kunnen bekijken) mee gaan werken en daar ben ik er 1 van. Het aantal gebruikers is klein en zal langdurig hetzelfde blijven.