AUXDB is an ADC which can be used to present two physical databases as one database to application programs. In general it is envisaged that the data dictionaries of both databases will be identical. The most common use of AUXDB is to extend the "split database" facility of QAB. This ADC will be added (together with its source code) to the ADC pack in the next release of DP4.
Ensure the dictionary of both databases is identical. If you have two existing and different databases which you now want to access as one database then you need to use some combination of COPYDB,UNLOAD/LOAD and RECASTDB -BYNAME to transfer the data from the two databases to two new databases with identical dictionaries.
An example startup section for loading AUXDB is as follows:
[startup]
1=dp4srvr.w32 -aux
2=auxdb.w32 -db time2 -auxdb time2alt -file c:\dp4\win\time2alt.txt
time2alt.txt contains a list of the application tables whose data is to be stored on time2alt rather than time2. The file should be a text file with one table listed per line.
It is largely immaterial which database is designated as the "db" database and which is the "auxdb" database. However if you are already using the QAB split database facility to store QAB and map dictionary data on one database, and application data on the other database and do not want to use any more databases then you are recommended to specify the map database as the "auxdb" database and to transfer some of the data tables to it. When deciding which tables to transfer you should bear in mind the limitations listed below.
You can also specify tables using -table tablename as many times as necessary on the command line to auxdb.w32, e.g.
2=auxdb.w32 -db time2 -auxdb time2alt -table customer -table employee
Compared with a standalone configuration using DP4SRVR.W32 the performance of the database manager may be reduced by around 25% when AUXDB is loaded, (the degradation is somewhat worse on Windows 9x than Windows NT). This is because of the extra IPC. However the overall performance impact will typically be much less - especially where DP4 networking is in use. (For example QAB uses block fetches to optimise window access, and the overhead of the extra IPC is a fixed amount so will be comparitively less on a block fetch than a single fetch). It would be possible, but difficult, to link the AUXDB code directly into PROGRUN. This would remove the performance hit.
A transaction which updates both databases is processed as two separate transactions - one for each database. It is therefore possible that an inconsistent database will be created.
It is the programmers responsibility to design the split between the databases so that only one database is updated in a transaction.
Programmers should beware of posting records with PARENT_CHECK or deleting records with either ORPHAN_CHECK or CHILD_DELETE. In the case where the child or parent records are on the other database the wrong parents or children will be processed.
Subject to the level of interest shown in this program by customers, we may enhance AUXDB in the following ways:
It would be possible to extend AUXDB to allow a database to be split between more than two physical databases.
The processing of commits could be enhanced to use proper two phase commits. However the operation of two phase commits in DP4 is dependent on TCPMGR being loaded, so this would not be easy.
Beta software is supplied without warranty and should not be used in live sites without the agreement of Itim Technology Solutions. Compatibility with an eventual final release cannot be guaranteed.