Hello,
Our project installs an ODBC driver which we want to treat as a "private copy" (the driver dlls are under our INSTALLDIR, and the driver name differs from the original one) in order to avoid version conflicts in the future.
Moreover, the driver, all the DBMS-related components and the database we install are marked permanent, so that the user can access the database contents even after uninstalling our software.
This makes the following scenario possible:
User deinstalls the software.
User notices that some folders/files under our installation directory are left over and deletes them. At this moment, user does not care about purging the registry (ODBC driver). - I think this a realistic behaviour...
Somewhat later, user installs our software again.
Now the fact that there is a driver entry in ODBCINST.INI seems to bring SetODBCFolders into trouble. The log file says:
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
SetODBCFolders: forcing location to System32
Started by
Matthias1967
, Jun 30 2010 15:37
1 reply to this topic
Matthias1967
-
- Full Members
- 92 posts
Posted 30 June 2010 - 15:37
| QUOTE |
Action 10:39:30: SetODBCFolders. Initializing ODBC directories Action start 10:39:30: SetODBCFolders. MSI (s) (9C:4C) [10:39:30:167]: Generating random cookie. MSI (s) (9C:4C) [10:39:30:213]: Created Custom Action Server with PID 2712 (0xA98). MSI (s) (9C:3C) [10:39:30:323]: Running as a service. MSI (s) (9C:3C) [10:39:30:323]: Hello, I'm your 32bit Impersonated custom action server. MSI (s) (9C:D0) [10:39:30:745]: LocalSQLInstallDriverEx returned 1 in remote context. ODBC driver MyBrandedDriver forcing folder DRIVERDIR to C:\WINDOWS\system32 MSI (s) (9C:D0) [10:39:30:760]: PROPERTY CHANGE: Modifying DRIVERDIR property. Its current value is 'C:\Programme\MyCompany\MyDBMS\'. Its new value: 'C:\WINDOWS\system32\'. MSI (s) (9C:D0) [10:39:30:760]: PROPERTY CHANGE: Modifying DRIVERDIR property. Its current value is 'C:\WINDOWS\system32\'. Its new value: 'C:\WINDOWS\system32'. MSI (s) (9C:D0) [10:39:30:760]: DRIVERDIR folder has been set to 'C:\WINDOWS\system32' MSI (s) (9C:D0) [10:39:30:760]: Note: 1: 2205 2: 3: ODBCTranslator MSI (s) (9C:D0) [10:39:30:760]: Note: 1: 2228 2: 3: ODBCTranslator 4: SELECT `ComponentId`,`Description`,`Directory_`, `ActionRequest`, `Installed`, `Attributes` FROM `ODBCTranslator`, `Component` WHERE `ODBCTranslator`.`Component_` = `Component` AND (`ActionRequest` = 1 OR `ActionRequest` = 2) Action ended 10:39:30: SetODBCFolders. Return value 0. |
System32 is a folder where we do not want our "private" driver to go in any case.
So why does SetODBCFolders accept neither the path that is still in ODBCINST.INI before the installation nor the set target path of the ODBC driver component?
(In this example, both are 'C:\Programme\MyCompany\MyDBMS\')
Do I have to explicitly delete those ODBCINST.INI entries if the driver dll is not there? (Yes, everything works fine if ODBCINST.INI has been cleared.)
Or is there a simpler solution?
Regards,
Matthias
Matthias1967
-
- Full Members
- 92 posts
Posted 01 July 2010 - 09:45
Hello,
I have now deactivated the action SetODBCFolders by setting its condition to a literal 0.
This avoids redirecting the target location of our ODBC component to System32.
However, I am not quite sure about possible risks induced by deactivating this action.
Any ideas?
Regards
Matthias
I have now deactivated the action SetODBCFolders by setting its condition to a literal 0.
This avoids redirecting the target location of our ODBC component to System32.
However, I am not quite sure about possible risks induced by deactivating this action.
Any ideas?
Regards
Matthias