>Here I'd heard so much about this Universal Thread. OOOhhhh. "You can get all the answers you want". "These guys really know what they're talking about". That's all I've heard for ages. So I post one simple question about using 16 Bit Drivers in VFP 5.0 environment and you all run away. Not one reply! So I'll try again.
>
>We are trying to access 16-Bit SQLBase data that is in a seperate payroll application (not ours) from our application. We got the drivers we need but because our app is in VFP5.0 it does not let us see the 16-Bit drivers. We then tried creating the link using VFP3.0 and shelling to it from VFP5.0 except Microsoft jam that too by giving the error message "Compiled in a previous version blah, blah, blah".
>
>Has anyone got any work around ideas for running 16 Bit SQLBase Drivers from VFP 5.0??

Hi Bruce,

SET RANT ON
Like Evan, I'm "guilty" of singing UT's praises to you.

The vast majority of the community here are volunteers, under no obligation to answer your questions. You're entitled to your opinion on the quality of help available here, but it seems clear to me that you haven't spent much time here. I know of no better help source - definitely including Microsoft itself.

If your comments were simply to "stir things up", well, they worked. And it's another tribute to the UT volunteers that they still manage to respond professionally.
SET RANT OFF

I'm also guilty of suggesting VFP3 to Jim Gray and I'm sorry if you've had problems with it. Approaches I would take:

- If you can't get a definitive answer from UT, call MS and ask them if 16-bit ODBC drivers can be used with VFP5 or VFP6. MS is generally pretty good for simple yes-or-no answers like that.

- If the answer is no, check out VFP3. I only suggested this to Jim because VFP3 has feet in both the 16- and 32-bit worlds.

- Using VFP3, can you successfully connect to the SQLBase data through the 16-bit ODBC driver? If no, I can't think of anything else to try.

- If you can connect using VFP3 you should be able to create an .EXE that can do the work you need. You can then call this .EXE from VFP5 or VFP6.

- If you're having problems with calling the VFP3 .EXE, check out the files section here. VFP5 is definitely capable of starting up any other Windows app - if RUN /N doesn't work, I think Ed Rauh (and or George Tasker?) have uploaded Win32API functions that will let you do this easily (API_RUN?) You can't use DO MyVFP3App.EXE, this will give you the error you saw.

As I said to Jim, you'll need to have VFP3 runtime installed on any machine that needs to run the VFP3 executable. You could try putting the VFP3 runtime .DLLs in the same directory as the .EXE if all else fails, but if I recall correctly the .DLLs are named differently between different versions so there shouldn't be a conflict.