Jump to content

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

1 reply to this topic


  • Full Members
  • 92 posts

Posted 30 June 2010 - 15:37


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:


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?




  • Full Members
  • 92 posts

Posted 01 July 2010 - 09:45


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?