Borland Database Engine and BDE Merge Module
Hey all,
Just wanted to highlight something that I have encountered with the hope someone may have come across it before.
- If you have BDE installed on your machine. Then you have another application which needs to configure 2 alias (hence update the idapi32.cfg file) using the BDE Merge Module.
When you install this second MSI which uses the BDEMERGE.INI to update the alias, it cannot update 2 of them correctly - the first alias gets updated fine, the second gets created but with the wrong properties. The quick and dirty fix for this is a second MSI to install the second alias....
- The second issue is, if you have BDE installed on your machine along with the second app that creates the 2 alias in the idapi32.cfg file. Then in the future you have a new version of the second application that uses the same alias names but with different properties. When you re-deploy it doesn't update the config file - you would need to delete the cfg file first and then install your new app. But you can't really be deleting it because some users may have extra alias or configuration info stored in that file.
Would you agree that this file should be treated like the tnsnames.ora and and managed seperately and centrally by your DBA?
Hope I explained that alright.
Cheers,
Aidy.
Just wanted to highlight something that I have encountered with the hope someone may have come across it before.
- If you have BDE installed on your machine. Then you have another application which needs to configure 2 alias (hence update the idapi32.cfg file) using the BDE Merge Module.
When you install this second MSI which uses the BDEMERGE.INI to update the alias, it cannot update 2 of them correctly - the first alias gets updated fine, the second gets created but with the wrong properties. The quick and dirty fix for this is a second MSI to install the second alias....
- The second issue is, if you have BDE installed on your machine along with the second app that creates the 2 alias in the idapi32.cfg file. Then in the future you have a new version of the second application that uses the same alias names but with different properties. When you re-deploy it doesn't update the config file - you would need to delete the cfg file first and then install your new app. But you can't really be deleting it because some users may have extra alias or configuration info stored in that file.
Would you agree that this file should be treated like the tnsnames.ora and and managed seperately and centrally by your DBA?
Hope I explained that alright.
Cheers,
Aidy.
0 Comments
[ + ] Show comments
Answers (0)
Please log in to answer
Be the first to answer this question
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.