Tomek, > It seems that either way, you're going to need to do coding of most > of the display functions. I understood the suggestion to be the > following: extend all of the basic types with a hidden field > "department" that is populated from the LDAP directory. Then you > would have to code the main display functions (objectAdmin, library, > etc.) to always include "where department IS > #session.dmProfile.department#" in the queries. That way, you could > keep things under one install.
An interesting idea. I'd have to think that through a little more though (I can see things going badly). > However, perhaps one other aspect to think about is database size > and speed. With the amount of things in the refObjects table (just > 60 depts * 300+ pdfs = 18,000 in just pdfs) then you add in all the > rest of objects that need to be stored (profiles, logs, etc) and you > get a whopping database I would think. Just wanted to point that out > though! Fortunately I'm not worried about table sizes. This client is using MSSQL Enterprise. I've run MSSQL databases with tens of millions of records per table and have not had an issue in the past going all the way back to SQL 7 (as long as your DBA sets up the DB and tables correctly). But thanks for the concern there (a valid point where in some databases you could see some serious repercussions or a poorly managed DB can get very slow). Regards, -- Jeff Coughlin Web Application Developer http://jeffcoughlin.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "farcry-dev" group. To post to this group, send email to farcry-dev@googlegroups.com To unsubscribe from this group, send email to farcry-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/farcry-dev?hl=en -~----------~----~----~----~------~----~------~--~---
