I'll take it as read that you have a solid reason for commingling the data from your various clients.
Something I've seen and like too is along the lines of Filter_AfterSearch(->[Table]) So, after *any* search, you run a filter against the table. This can be used for all sorts of things: -- Exclude records marked 'deleted' -- Filter records based on the user's role. A Manager might see more records than a Floor_Worker (or the other way around.) -- Filter by some kind of location setting. -- What you were talking about. You can implement the Filter_AfterSearch method however you like, I've regularly seen big case statements with hooks for tables with special filter rules. There are more involved ways, but a "case of" is an easy way to start and experiment. It's also easy in Filter_AfterSearch to check that the table has a selection before you worry about filtering it. If you use the standard query editor, then you need code to bring up the editor which is immediately followed by a call to Filter_AfterSearch. That should do it. Just remember to do the same with your custom queries too so that you don't leak data from other customers. The good part is that you still just need the one line of code: Filter_AfterSearch(->[Table]) ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
