> And now we're into REGEDIT?

All ShellExecute does is to call REGEDIT transparently...that being the application associated with .REG files.

> Now, in your recent Advisor article on this subject, you mentioned that there is no need to put information about your DSN in the ODBC Data Sources subkey, especially to keep people from breaking your DSN connection, but you still need two things, right? You need the connection defined in ODBC.INI and you need the driver defined in ODBCINST.INI, correct?

Yes, the driver information must be there (that's done by the driver installation anyway). When you create the DSN you don't actually need to create the entry in ODBC.INI because that is only required if you want the DSN to appear in the list of connections that is produced by Windows.

> Here's the problem that has me bloodying my forehead against my monitor. I am writing a Fox app that needs to talk to and monitor a third-party app that was written in Delphi. They advocate using the DBISAM driver to talk to their database, and the version of DBISAM that I purchased allows for a run-time version to be freely distributed with my app. So far, so good.
>
> So, I drop the DBISAM driver DLL into my distribution directory and set up a ODBC.INI setting pointing to it, but that connection cannot be found in Foxpro. I try manually setting up the connection (in code) but all I get are connectivity errors. I try setting up a connection string and - well, don't get me started on all the "unrecognized phrase or keyword" errors and "no driver found" messages I waded through with that attempt! OBVIOUSLY, I do not understand ODBC/DSN magic.

Don't you have to register the DLL? I would have thought it had to registered in order for the driver to be in the ODBC registry. Just putting in the distribution directory won't register it.

Regards
Andy Kramek
Microsoft MVP (Visual FoxPro)
Tightline Computers Inc, Akron Ohio, USA