32-bit and 64-bit Applications Accessing the Same Database
These considerations are particularly important when deploying an application into a production system:
|
Do not create mixed 32-bit and 64-bit applications |
To avoid complexity, it is recommended that applications are either 32-bit or 64-bit. For example, if you use both 32-bit and 64-bit clients when using SuperServer, only use a 64-bit server. Because the clients are not directly accessing the database, there is no complication. |
|
Auto-generate relative record numbers |
Assign relative record numbers using auto-generation. If relative record numbers are assigned using external files, duplicates will occur unless the RPTH parameter is assigned to the same path for both 32-bit and 64-bit applications. A file that is currently using external files can be changed to use auto-generation using the Upgrade tool feature Convert Files to Use Identity Column. |
|
Database upgraded by first system upgraded |
Table upgrades are identified by comparing the previous CTD file to the new CTD file being installed. Thus only the first system upgraded should upgrade the database. This is why database upgrade defaults to off during an MSI install and why per-user installs disable database upgrade. |
|
Be consistent |
If an existing OAM is not there for 64-bit but is for 32-bit, and vice versa, the user needs to control which is the latest OAM. If 32-bit is the first environment to be installed, continue that way for all Upgrades and Patches. Once the 64-bit environment is at the same level, the Upgrade/Patch database change machine can be switched, but it is inadvisable. Be consistent and use one machine from the beginning. |