Larry,

Thank you very much for what I know is an informed answer. I am concerned about the frequent switching between databases that may be required, but I am keeping it in mind as I proceed.

I am rather pleased with the migrator that I have been developing. It does a lot of things automatically, including using a view for data entry instead of memory variables and SCATTER/GATHER. It also converts global vars to properties of a biz object and more. Because of diminishing returns with the automatic conversion I am now moving to the manual conversion phase.

Thanks again,

Alex

>Alex,
>Break them out according to different or not. If AppInfo and ReportCatalog are going to be the same, then put those in your central DBC.
>
>GeneratePK will have to be separate for all DBCs. You will probably have the same table names, so you can't centralize that. Also, you will have to create different user objects depening on what company your are dealing with or you could subclass the user object and add that functionality.
>
>CusUsr has properties you can set for database and table name. It uses these when creating itself. The same is true of the security object.
>
>HTH.
>
>>Hi,
>>
>>I have a situation with different companies in different directories that is mentioned in the VMP manual. As indicated there, I plan to call x3dbcpth in Form.DataEnvironment.BeforeOpenTables() right after the call to ThisForm.DEBeforeOpenTables().
>>
>>My question is this: Should I have for each company a DBC that contains all the VMP specific files (AppConfig, AppInfo, GeneratePK, ReportcCATALOG, etc.) as well as my app specific files, or should I try to split them into two DBCs, one global to the app and the other specific to each company?
>>
>>The problem is, some of the VMP tables, such as AppInfo, ReportCatalog, and perhaps others, will be identical for each company at a particular site but others, such as GeneratePK, should be different for each company.
>>
>>What do you all suggest ?
>>
>>TIA,
>>
>>Alex