sefanja

Natuurlijk kan het op andere manieren ook, maar elke workaround maakt het programma ondoorzichtiger. (Momenteel gebruik ik de goede tip van Jeroen Aarts in bericht 2.) Als FM dit gedrag echt zo bedoeld heeft, ben ik teleurgesteld in de ontwikkelaars. En wat me dan vooral tegenvalt, is dat dit gedrag niet duidelijk gedocumenteerd is. Ik zou bijna denken dat ze (achteraf?) zeggen dat het zo bedoeld is omdat ze dan geen prioriteit hoeven te geven aan deze bug. Dit vreemde gedrag past toch onmogelijk in hun filosofie om de ontwikkeling van database-gebaseerde toepassingen eenvoudig te maken?

Resultaat van de portal is uiteraard wel goed omdat die gebaseerd is op Reservations. Die tabel heeft een directe relatie met zowel Rooms als Users waardoor er rekening gehouden wordt met de sorteervolgorde. Het (samenvoeg)veld is echter gebaseerd op Rooms en geeft dan ook een verkeerd resultaat voor Users (200=100) omdat er geen directe relatie bestaat tussen Rooms en Users. Pas dan wordt de sorteervolgorde genegeerd. Een portal is in mijn geval niet handig omdat ik in de layout naast het kamernummer de foto wil laten zien van de laatste gebruiker.

Heb er een bug report van gemaakt:

Lijkt mij toch dat in dit geval functionaliteit prioriteit zou moeten krijgen boven efficiëntie? Zo lang duurt het nou ook weer niet om records te sorteren. FileMaker zou een gemakkelijk databaseprogramma moeten zijn. Dit relatiegedrag ligt niet in die lijn, lijkt me. Hoe leg je een Request for Change voor bij FileMaker? Heb trouwens ontdekt dat de sortering wel gerespecteerd wordt als de koppeling over hetzelfde veld verloopt. Het gaat dus bijvoorbeeld wel goed bij de volgende relaties: Furniture::RoomID = Rooms::RoomID; Rooms::RoomID = Reservations::RoomID

Het lijkt erop dat FileMaker geen records kan sorteren als een relatie zich over meerdere tabellen uitstrekt. Een voorbeeld: Drie tabellen: Rooms RoomID RoomNumber [*]Users UserID UserName [*]Reservations RecordNumber (auto increase) RoomID UserID De volgende relaties zijn aangebracht: Rooms::RoomID = Reservations::RoomID Users::UserID = Reservations::UserID Omdat ik wil dat FileMaker in de verschillende layouts altijd de meest recente reservering weergeeft, heb ik in bovenstaande relaties opgenomen dat de records uit Reservations gesorteerd moeten worden op RecordNumber, van hoog naar laag. Er staan twee records in Reservations: RecordNumber: 1 RoomID: 23 UserID: 100 RecordNumber: 2 RoomID: 23 UserID: 200 Als ik vervolgens een layout maak aan de hand van de tabel Rooms met het volgende samenvoegveld: <>; <>; <> Dan is dit het resultaat: 23; 200; 100 Het lijkt er dus op dat wanneer Rooms info nodig heeft uit Users, FileMaker geen rekening houdt met de sortering die aan is gegeven in de relatie tussen Rooms en Reservations. Voor de duidelijkheid: er bestaat geen directe relatie tussen Rooms en Users, die loopt namelijk via Reservations. Rooms::RoomID = Reservations::RoomID; Reservations::UserID = Users::UserID Is dit een fout van de ontwikkelaars van FileMaker? Of is dit gedrag opzettelijk zo bedoeld? Wat is de beste workaround?

<% strUserID = Request.QueryString('UserID') + ''; Response.Write(''); %>