Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
One software Multi-companies
Message
 
 
To
28/03/2010 16:53:47
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 9 SP2
Miscellaneous
Thread ID:
01457588
Message ID:
01457725
Views:
56
>>>>>>>What would be the best way to make a software multi-companies. I use Stonefield Database Toolkit. Would SDT make things easier?
>>>>>>>
>>>>>>>Overall Feedback?
>>>>>>
>>>>>>Hi Denis,
>>>>>>
>>>>>>I definitely would recommend SDT. I have a vertical market application used by many different companies. And I use SDT in such way that even though the database is the same, different tables can have custom fields (additional fields) without me having to customize the application.
>>>>>
>>>>>Hi Dmitry,
>>>>>
>>>>>Yes it could be a way to do it but what about creating multiple databases. 1 database per company. How could SDT manage this? Would it be able to still to manage this with the updates and everything?
>>>>>
>>>>>By the way I created another thread in the Stonefield category. You can also reply there if you want. I thought creating it in that category would be better suited for my problem.
>>>>>
>>>>>Thanks
>>>>
>>>>From Sergey's message I presume that he is not much in favor of putting records of multiple companies into the same tables. And I thought of another approach you might want to consider. Probably much more involved but still an alternative. You could have a suffix number added to the database container and all tables for each company "database". E.g. Database01.d??, TableA01.dbf, Table01, Database02.d?? and so on. Then whenever you open a database or a table you would need to have the code to use the name with the appropriate company suffix.
>>>>
>>>>HTH.
>>>
>>>
>>>That's a nightmare you're proposing.
>>>Best is a company Id in the tables.
>>>
>>>Next best is one db per company
>>
>>What I was proposing is also one db per company, just using a certain naming convention.
>
>As long as each company has its own database. Unless the companies are tied together in some way (same parent company for example and management will want reports that cover all companies (sales to a customer across any company, supplies bought from a vendor across any company, profit from a single product across any company, etc.), each should have its own database. General practice is to have one database per balance sheet or tax ID. Will the companies pay for specific security, hardware, or backup/replication? Do the companies have different auditing and/or data storage requirements? It really all depends on the type of app and the type of customers...

I agree; it all depends on the specific business requirements. I was just offering one approach. And when I think about it, it could be the easiest to implement. Here is how I would do it (if each company could have a completely separate database):
1. Refactor the entire application to use a variable instead of hard-coded table or database name when it is used. E.g. cCustomerTable, cInvoices, etc.
2. At the top of the application, once user selects a company, populate table and database names into variables. E.g.
cCustomerTable = "custdbf" + padl( nCompId, 2 )
cInvoices = "invdbf" + padl( nCompId, 2).
3. Instead of addressing each table hard-coded, use a variable.
E.g. Use (cCustomerTable) in 0 alias CUSTOMER

Another advantage of the above approach is that index structure does not have to be changes (as opposed to when using a Company Number field in the tables).
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
Previous
Reply
Map
View

Click here to load this message in the networking platform