AnsweredAssumed Answered

Using globals for record level access in hosted environment = problems

Question asked by samgiertz on Aug 19, 2013
Latest reply on Apr 21, 2014 by padaddy

We are going multi-country with our internal solution, hosted on the same server and using the same database, client running full filemaker client. Main table contains about 50k rows and 100 fields. It is a bit slow over WAN but usable and we know we can improve the speed by doing things smarter.


We wanted to add record level access so users in each country only would see records belonging to their country. The idea was to set a global variable $$HomeCountry at login with the country name of the currently logged in user and then add record level read access like so: $$HomeCountry = OwnerField, where OwnerField contains the name of the country owning the record, set at record creation.


Access wise this works as planned, when browsing records the user get <no access> where he should get it. But when doing finds using this technique, users get "no records match your find request", even if just using a "*" in the record ID field. I understand in theory filemaker should automagically filter out records a user dont have access to when using finds, but in this case it all breaks.


We are forced to create a different privelege set for each country, granting read access when OwnerField = "USA", i.e. specifying the condition in clear text rather than using a variable. However now normal finds seems much slower over WAN.


Not done investigating this but clearly no the smooth ride we had hoped for. Any ideas on what we might be doing wrong or better approaches on handling multi tennant solutions would be greatly appreciated.