Multi-homed system in MS SQL Server
by Frank G. Vandervelpen
Summary
This white paper describes a way to tackle the problem that arises when you want to convert a multi-homed DataFlex database to MS SQL Server. By multi-homed we mean a database with shared datafiles in one directory and specific company-related datafiles in their own seperate directory |
No Files Available |
Date Created: |
17/11/1999 |
Date Updated: |
17/11/1999 |
Author: |
Frank G. Vandervelpen
|
Company: |
Velpe Development bvba |
How to make programs dynamic for several MS SQL Databases with the same database structure
The installation of SQL Server 6.5 was a standard installation. We have loaded support pack 5a on it, and we have increased the master database device to 1.25 GB. (i.e. the master.dat)
We have installed Mertech's Flex2SQL version 2.0 for DataFlex 3.1d Console mode and the Visual DataFlex Flex2SQL version 2.0 for Visual DataFlex version 6.
We have seen some conflicts with msvcrt.dll with vdf6. It should not give any problems with VDF5.1.
We have migrated the DataFlex files from the filelist towards SQL Server through the standard migration utility. Therefore, we have used the account sa and the appropriate password. We have selected a filelist and an environment file (cfg) to determine the source path.
Suppose following directory structure when migrating from DataFlex:
- M:\forks\data
: holds the shared databases
- M:\forks\Brownies
: holds the specific tables for company 1 and the databases are
the same as for the other 2 companies
- M:\forks\whities
: holds the specific tables for company 2 and the databases are the
same as for the other 2 companies
- M:\forks\yellowies
: holds the specific tables for company 3 and the databases are
the same as for the other 2 companies
When we migrate these towards SQL Server 6.5 we can't place these things into databases. So the tables will be placed in separate tables. We have tested relationships over several SQL Databases and this works because we have defined them in the .int file. However, the DATABASE_SPACE_NAME is not defining which SQL-database to use. This is defined in the .td file. However, these are necessary to open the convenient SQL Database.
Therefore, making it dynamic was not the easiest part.
What we have done is first open all mutual (shared tables). Once that we have done this, we are defining the new SQL-Database to use for the company-dependent tables.
This leads to the situation where we have the following code:
SET_DATABASE_NAME to sValue open kids |
where sValue is the name of the SQL-Database. All files opened after the Set_database_name will try to open the table in the SQL-Database indicated, rejecting the parameter in the .td file. Don't forget to close the file before reopening it to get the new SQL-Database.
On the left hand site is the layout from a point of view of the SQL Server
|