Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Randy Smith
  Where is Randy Smith?
 Hudson
 Wisconsin - United States
 Randy Smith
 To: Andy Kramek
  Where is Andy Kramek?
 Hot Springs Village
 Arkansas - United States
 Andy Kramek
 Tags
Subject: RE: Why ODBC and Not OLEDB?
Thread ID: 110533 Message ID: 115081 # Views: 13 # Ratings: 0
Version: Visual FoxPro 9 Category: ODBC, ADO and OLEDB
Date: Tuesday, December 5, 2006 1:25:04 AM         
   


> > 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.
> *************
> 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.

Andy and all who are monitoring this thread:

I am out of triage, through the operating room, and have finally completed my setup routine. I lost a couple of pints of blood, but I'm good to go now. I wanted to share with you and the rest what I found in order to save someone else from taking stitches to the forehead as well. Additionally, someone out there may have some further insight for me and all that is -- as always -- most welcome!

To preview: I have a Fox app that needs to talk to a Delphi database. I can distribute my dev-version-purchased dbisam driver royalty free, per the ElevateSoft agreement, and I needed to make my install routine put this driver into place and hook it up with my Fox database and create the views with no user intervention; it needed to be absolutely invisible with no technical input from the user whatsoever.

Using code I found on news2news (http://www.news2news.com/vfp/) that supplied me with Fox code for using Win32 API's, I first determine dynamically where the "C:\Program File" directory is as that is where my install is supposed to be (that type of information -- where the special Windows folders are -- can be found at http://www.news2news.com/vfp/?group=91&function=659 -- look for the API function SHGetFolderPath, but you'll have to buy a membership to get their solution for it; they do provide the API call for free, though). I provide in one of my subdirectories in C:\Program Files\MyApplicationFolder a "driver" folder that contains the dbisam odbc dll. I do not need to use regsvr or anything else on this, other than making the registry entries.

NOTE!! In this case I HAD TO put the driver name into the HKEY_LOCAL_MACHINE\ODBC\ODBC.INI\ODBC Data Sources list in order for this to work "invisibly". If I did not, then the ElevateSoft dbisam driver auto-initiated a request to set up the driver by popping up a dialogue and waiting for user input! Aaaaack! I tried many times to trick this and bypass this step in order to keep the visibility of this connection out of the users realm -- to no avail. The only solution was to include my connection name in the aforementioned data sources list, and then I was able to achieve setup invisibility (but the user can see the connection now if they go into the Control Panel / Admin... / ODBC...).

Therefore, I ended up setting up ALL of the registry settings for the driver, the odbc connection, and listed it in the drivers list to boot. I was then able to create the Foxpro database connection and set up the remote views with little problem. I could not get either the ShellExecute of regedit or the RUN of regedit to operate properly in a "silent" mode and let me run .REG files or what-have-you. I had to go with using the registry foundation class and set them all up manually; luckily, with the registry class, this was not difficult. For example:

* Registry roots
#DEFINE HKEY_CLASSES_ROOT -2147483648 && BITSET(0,31)
#DEFINE HKEY_CURRENT_USER -2147483647 && BITSET(0,31)+1
#DEFINE HKEY_LOCAL_MACHINE -2147483646 && BITSET(0,31)+2
#DEFINE HKEY_USERS -2147483645 && BITSET(0,31)+3

STORE .T. TO llCreateKeyIfNotExist
SET CLASSLIB TO registry && We are going to access the registry
oReg = CREATEOBJ('registry.registry') && Create object based on class

STORE "SOFTWARE\ODBC\ODBCINST.INI\DBISAM 4 ODBC Driver" TO lcKeyPath
oReg.OpenKey( lcKeyPath, HKEY_LOCAL_MACHINE, llCreateKeyIfNotExist )
oReg.SetRegKey( "APILevel", "1", lcKeyPath, HKEY_LOCAL_MACHINE )
oReg.SetRegKey( "ConnectFunctions", "YYY", lcKeyPath, HKEY_LOCAL_MACHINE )
....

and so forth. I know I would have killed for the snippet of code above just a short week and a half ago, so I hope this helps someone else out! Just make sure you've added the registry class to your project before you try executing this (or use something like LOCAL oreg as "registry" OF HOME()+"samples\classes\registry.prg" which I found in a Calvin Hsia blog entitled "Put Your Registry Into A Table" at http://blogs.msdn.com/calvin_hsia/archive/2005/05/05/415044.aspx while I was trying to figure out why to use and how to use enumkey.)

So, there you are. Good day!

UPDATE: One final note to anyone who intends to use the above information for setup rather than ongoing monitor and such -- check out what InstallShield Express for Fox gives you (you should have received that with your VFP 9 package). Most of the above, if not all, can be handled for you and save you weeks of programming by just letting InstallShield handle it.

RLS

ENTIRE THREAD

Why ODBC and Not OLEDB? Posted by Dexter Carlit @ 10/19/2006 10:00:17 PM
RE: Why ODBC and Not OLEDB? Posted by Pete Sass @ 10/20/2006 2:44:12 PM
RE: Why ODBC and Not OLEDB? Posted by Dexter Carlit @ 10/20/2006 5:22:23 PM
RE: Why ODBC and Not OLEDB? Posted by Pete Sass @ 10/20/2006 7:30:36 PM
RE: Why ODBC and Not OLEDB? Posted by Ken Murphy @ 10/20/2006 7:37:19 PM
RE: Why ODBC and Not OLEDB? Posted by Bernard Bout @ 10/23/2006 10:38:51 AM
RE: Why ODBC and Not OLEDB? Posted by Ryan Lashway @ 12/4/2006 9:02:45 PM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 10/23/2006 1:57:47 PM
RE: Why ODBC and Not OLEDB? Posted by Eric den Doop @ 10/23/2006 2:43:15 PM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 10/24/2006 12:17:38 PM
RE: Why ODBC and Not OLEDB? Posted by Nilson Rishi @ 10/23/2006 3:32:12 PM
RE: Why ODBC and Not OLEDB? Posted by Ken Murphy @ 10/23/2006 6:37:52 PM
RE: Why ODBC and Not OLEDB? Posted by Nilson Rishi @ 10/24/2006 5:17:33 AM
RE: Why ODBC and Not OLEDB? Posted by Bernard Bout @ 10/24/2006 6:18:13 AM
RE: Why ODBC and Not OLEDB? Posted by Nilson Rishi @ 10/24/2006 8:31:50 AM
RE: Why ODBC and Not OLEDB? Posted by tushar @ 10/24/2006 7:22:47 AM
RE: Why ODBC and Not OLEDB? Posted by Nilson Rishi @ 10/24/2006 10:00:29 AM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 10/24/2006 1:32:41 PM
RE: Why ODBC and Not OLEDB? Posted by tushar @ 10/25/2006 9:14:35 AM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 10/25/2006 1:10:22 PM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 10/24/2006 12:26:39 PM
RE: Why ODBC and Not OLEDB? Posted by Nilson Rishi @ 10/24/2006 1:03:04 PM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 10/24/2006 1:21:46 PM
RE: Why ODBC and Not OLEDB? Posted by Pete Sass @ 10/24/2006 10:23:04 PM
RE: Why ODBC and Not OLEDB? Posted by Ken Murphy @ 10/25/2006 1:05:40 AM
RE: Why ODBC and Not OLEDB? Posted by Nilson Rishi @ 10/25/2006 4:31:57 AM
RE: Why ODBC and Not OLEDB? Posted by tushar @ 10/25/2006 9:28:28 AM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 10/25/2006 3:04:41 PM
RE: Why ODBC and Not OLEDB? Posted by Pete Sass @ 10/25/2006 4:10:42 PM
RE: Why ODBC and Not OLEDB? Posted by Ken Murphy @ 10/25/2006 4:47:32 PM
RE: Why ODBC and Not OLEDB? Posted by Bernard Bout @ 10/25/2006 6:13:41 PM
RE: Why ODBC and Not OLEDB? Posted by Ken Murphy @ 10/25/2006 6:40:19 PM
RE: Why ODBC and Not OLEDB? Posted by Bernard Bout @ 10/26/2006 5:55:08 AM
RE: Why ODBC and Not OLEDB? Posted by Ken Murphy @ 10/26/2006 2:33:34 PM
RE: Why ODBC and Not OLEDB? Posted by Bernard Bout @ 10/26/2006 11:33:28 PM
RE: Why ODBC and Not OLEDB? Posted by Randy Smith @ 11/28/2006 8:59:48 PM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 11/29/2006 1:15:09 PM
RE: Why ODBC and Not OLEDB? Posted by Randy Smith @ 11/29/2006 2:58:16 PM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 11/29/2006 7:27:04 PM
RE: Why ODBC and Not OLEDB? Posted by Randy Smith @ 11/30/2006 11:14:13 PM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 12/1/2006 1:00:35 PM
RE: Why ODBC and Not OLEDB? Posted by Randy Smith @ 12/1/2006 4:03:51 PM
RE: Why ODBC and Not OLEDB? Posted by Andy Kramek @ 12/1/2006 5:21:24 PM
RE: Why ODBC and Not OLEDB? Posted by Randy Smith @ 12/5/2006 1:25:04 AM
RE: Why ODBC and Not OLEDB? Posted by Glenn Villar @ 2/24/2009 4:28:19 AM
RE: Why ODBC and Not OLEDB? Posted by Boudewijn Lutgerink @ 10/27/2006 11:33:27 AM
RE: Why ODBC and Not OLEDB? Posted by Ken Murphy @ 10/27/2006 2:27:33 PM
RE: Why ODBC and Not OLEDB? Posted by Boudewijn Lutgerink @ 12/5/2006 12:55:03 PM
RE: Why ODBC and Not OLEDB? Posted by Ken Murphy @ 12/5/2006 3:12:45 PM