Software Deployment

I repackaged this application recently and I don't recall a specific problem with ODBC. Normally, I'd expect to see this message if the workstation had MDAC issues. Try installing the latest flavour of MDAC and re-try.

Also, the app uses MDBs (MS Access database files) so ensure that the MS Access driver is present. Of course, a full MDAC install will take care of that. Have your workstations installed a mix of MS Access runtime and retail versions at any time? This has caused issues in the past.

Lastly on the ODBC side, I now others haven't experienced problems but I routinely remove ODBC stuff from the ODBC tables and use the Registry table instead. It's easy to export the relevant entries once you have a capture, delete the ODBC table rows and then import the .REG into your project. YMMV.

As an aside, I had to retain the key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9AE75F3B-C633-49C5-BC55-E8144093CE58}'

because the application tests for its presence during start-up and, if not present, displays an error message:

Hi Ian,

Curious to know whether it is right approach not to use ODBC tables and use registry instead.
I have found issues previously using ODBC tables but still would like to know is registry way the right thing to do ?

I think the official line is to use the ODBC tables - why else would they be there? - and people here and elsewhere have said that they don't have a problem with those tables. However, it's simply a decision I took a while ago, after WPS (5.6, IIRC) consistently screwed up ODBC entries at a client site. It was completely reproduceable and wasn't dependent on machine type, driver being used or any of the major variables involved. Once I'd moved the relevant entries to the Registry table, all the issues went away. Now, it's just habit.

Hi ,

As u said i used the registry entry and remove the ODBC entry from the table... Now i didnt get thet Error 1918.
But tat ODBC entry Openedge doesnt get listed in the Administrative Tools -> ODBC Drivers.

ORIGINAL: ninu

Hi ,

As u said i used the registry entry and remove the ODBC entry from the table... Now i didnt get thet Error 1918.
But tat ODBC entry Openedge doesnt get listed in the Administrative Tools -> ODBC Drivers.
That's because the app doesn't install a driver but a DSN: the driver it uses is the Microsoft Access driver.

You may need to update the ODBC.INI and ODBCINST.INI files located under WindowsFolder (C:\WINDOWS)

Check what the original installation adds to these.

ORIGINAL: VBScab

I think the official line is to use the ODBC tables - why else would they be there? - and people here and elsewhere have said that they don't have a problem with those tables. However, it's simply a decision I took a while ago, after WPS (5.6, IIRC) consistently screwed up ODBC entries at a client site. It was completely reproduceable and wasn't dependent on machine type, driver being used or any of the major variables involved. Once I'd moved the relevant entries to the Registry table, all the issues went away. Now, it's just habit.


I recall similar issues in earlier versions of WPS.

While it is true that the ODBC entries ultimately end up in the registry, I've actually seen cases where this didn't work. The trick was you had to condition the installation of the ODBC entry on the existence of the driver. Typically the packager will modify the ODBCDataSource table to fulfill an app requirement without regard to having ODBCDriver entries in place. I see no reason looking at msi.chm why this should not work ( the DriverDescription is nullable, so you should just be able to plop down a data source and have it work, assuming the driver is indeed there ), but I do recall setting Data sources without the driver being there, and having it fail. This is probably why the packaging "urban legend" got started that you should use the registry and not the ODBC tables. I have used both methods.

Well, at the client where this drove me nuts the most, it was the inconsistency of the behaviour that was maddening. On one project it would be fine, the next it would fail, whereas of course the registry route worked every time. As I say, I do it out of habit now and, of course, rarely have time for any "I wonder if it would work today?" type of testing.