>>>>Hi,
>>>>
>>>>I am writing a quote to a large company that needs a multi-site license of my software. Basically, if this goes through, they will use the software at different facilities. There will just ONE server and ONE database. Each table of the database has a column SITE_NO so that users of each facility can add/edit/view only their records. I think in some of the technical speaks they use the term "sandboxed" indicating separation of the data by a site. The managers I am dealing with are not very computer technical. Can I still use the term "sandboxed" or is there a better way to describe how the data will be separated by a facility?
>>>
>>>"Sandbox" is a term used in the security industry: https://en.wikipedia.org/wiki/Sandbox_%28computer_security%29
>>>
>>>You might also run into terms such as "isolation" or even "firewalling" but in your situation I'd be reluctant to use any of them, because from a technical POV they aren't true.
>>>
>>>The closest I can think of is "access control". Even with this you may need to be careful. For example, what if Site 2 gets a valid user name/password combination from Site 1? Should Site 2 be able to log on with those credentials and view Site 1's data? Or do they want to make it so no matter what credentials Site 2 uses, they can only ever see their own data?
>>>
>>>If they're using terms like "sandbox" they may want greater isolation/security than you may be able to easily provide with your current scheme. I suggest asking them how much they actually need vs. what they think they want. Then, be upfront in your quote about what you're providing, and its limitations, if any.
>>
>>Thank you for your message. Of course I will not use the terms like "isolation" and/or "firewalling" or I will never get an order. And I won't use the "sandbox"; too either technical or childish :). I will just describe in much detail how the program will work. But then again, in my experience, prospective customers never read the details of the quote but simply go to the bottom line, the price :). Then they expect it to work just like they think it "should" work :).
>
>It might be outside the scope of your quote, but it seems to me there's an opportunity for further added value. Another option would be to have separate databases at each site, with each of those replicating to a central server elsewhere. My understanding is that sort of thing is well established and not difficult to implement with modern RDBMSs such as SQL Server. This would allow remote sites to continue to work even if they lose their internet connection, and it would be one way to enforce that they only can work with or see their own data.
>
>Each table at each site would still have some unique identifier such as SITE_NO, which would allow site-specific or aggregate reports at the central DB site.

You are correct that "replicating" is outside of the scope of this project simply because I don't know anything about it. I am already over my head with what I have on the "plate." I have reached the "Peter's Principle" a long time ago :(.