I'm looking for some suggestions on the following topic:

My application needs to be multi-company. Users need to be able to create a new company at any time (perhaps by using a 1-user Developer OI for that purpose). As the application evolves after the initial deployment, I need to update the dictionaries for the tables in each company (all to the same common dictionary layout).

Therefore what I would like to do is place the dictionaries in one common directory and the data tables in separate directories, one for each company. So for example if I had companies X1 and X2 using a CUSTOMER table, there would be only one dictionary in a directory called DICT, and 2 data tables: one in the X1 directory and one in the X2 directory.

When creating a new company, what I would do is create a new directory and then create only the data tables (empty) using the Create_Table command in that directory. I would attach the corresponding dictionaries from the DICT directory.

When between switching companies, I would just attach the new data directory.

Also, at upgrade time, I would only update the dictionary layouts in the one dictionary directory, and be sure that every company has the new layouts.

So this is the plan. Is is feasible? Is it easy enough? Can you think of better ways of doing this? Is indexing going to be a problem?

What about using one field in a table as the company and then putting a filter on the data? Would that be done at the MFS level? Or can we create a filter like in a relational database?

I would appreciate any constructive feedback.

Thanks

Dave,

It seems that a lot of people are using the multi-directory approach towards handling multiple companies. I think the best approach depends on how these multiple companies operatate.

For instance, if individuals will normally only work in a particular company then a multi-directory setup is better since it shields the end-user from having to always choose the right company (assuming this was a field in the database).

If individuals "float" from one company to another (i.e. they get orders from various customers, but different customers need different companies), then a field in the database is easier than having that user "switch" companies each time and then enter the order.

A variation of the first option would be creating separate windows that are company specific. Each window would automatically fill in the appropriate company in the company field (visible or invisible to the end user) so you have the convenience of not forcing the end user to always choose the right company and you have the convenience of not having to create a new set of tables each time.

[email protected]

SRP Computer Solutions

Don,

I definitely agree with your logic. Basically, most users would log into one company and stay there. The only users that would want to switch "on-the-fly" would be the accounting users that want to apply cash, pay invoices, etc from different companies.

What I'm after is this:

1. Will the separated data/dictionary directory work? Are there any indexing problems I should be aware of (since one dictionary controls multiple data files that are attached/detached on the fly)

2. If I go with the extra "Company" field in some tables, can I set up views at the table level? I don't want to go back an re-do existing forms, popups and reports if at all possible. That's why I want to be able to put some sort of a filter AT THE TABLE LEVEL that only allows users to view the current company out of forms, popups and reports. I know I can do it with an MFS, but that's kind of cumbersome to write. Any good ideas about these filters?

Thanks in advance to Don and anyone else who is willing to shed some light on this.

Dave

A single dictionary shared between tables is the best way. Indexing itself will work fine. The only trick is in adding the new ones. That you might have to do progamatically by placing the proper records into the !files.

Outside of that, no MFS, just alias the dict files in. Once it's attached, as long as DICT.SOMEFILE exists, the dictionary is there, and it will be used and treated as such.

[email protected]

Sprezzatura, Inc.

Aaron,

Can you please elaborate some more on what the "proper" records are in the !files ?

Would programatically attaching each data table, removing the index, then adding it again do all that automatically? ( I'm thinking attach data table1. Add new index to a field. Then attach data table2. remove index. This will hopefully remove the index reference in the dictionary, but do nothing at the !level since there is no index there yet. Add index for data table2. Attach data table3. Remove index. Create index. And so on… )

What do you think?

TIA

Easiest thing to do is create the file and dictionary structure then create the indexes. Take this info and copy it off somewhere. Then, just create the !file by force if you have to and copy in the fresh index information.

The only thing you might have to do is kill the ! record and maybe change the volume reference in the !file record.

[email protected]

Sprezzatura, Inc.

View this thread on the forum...