>>>>Keeping data for all subscibers in common tables will make life a lot easier for reporting. For example, what if you want to know the total value of all orders for all subscribers for a given month? Much easier if the data for all subscribers are in the same tables.
>>>
>>>
>>>Maybe, but, as a customer, I wouldn't like that other customers can see at my data via SQL. I think that , for security reasons, separate data groups will be the way to go.
>>
>>No matter what type of backend you're using, you can use either a parameterized view, or a SPT string, both of which will contain the subscriber ID as a parameter. The user will only get back records that belong to him.
>
>Hi Al.
>
>Correct me if I'm wrong, but I think that scheme is easier to hack, since the user can access all the table information, making his calls outside the application.

If you're going outside the app, the situation is the same as with a VFP app and someone tweaking .DBFs using Excel, Access, etc. For the limited example of using .DBFs, you make a valid point. However, you can probably create a COM server to act as a middleman in any transactions to your VFP data, and make direct access to the tables difficult or impossible.
>
With a COM server or conventional RDBMS backend, you isolate the user from direct access to the tables, so it shouldn't really matter how you structure those tables.

One other thought - if you start with a VFP solution and hundreds or thousands of tables, how well would that scale or migrate to something like SQL Server if/when the time came? I don't have enough knowledge to be sure, but I suspect a SQL backend won't like running with that many individual tables, and creating more all the time.