For the record, I've traced back to when it was first noticed that the code as originally written stopped working properly. It was within days of having installed SP1 for VFP9. I have to assume that MS did something in the code of SP1 that broke something in the connections between VFP9 and the VFPODBC.DLL.

So far the solution essentially is as outlined below - I have to get rid of any User DSNs that use a driver containing "(*.dbf)" in its name. It's not a workaround that I much care for, but it sems to be the only thing that does work consistently.

If anybody has any light to shed on this, I'd really appreciate it.

>We have an application which uses Microsoft Word (among others) for mail merges. It uses ODBC. The app creates the user DSN on the fly using the {Microsoft Visual Foxpro (*.dbf)} driver. It's worked fine for a long time, but one day it stopped working properly (for a couple of our clients and for me). Whenever I'd try to do the mail merge, Word would pop up a box asking which driver I want to use. It gives a number of choices including dbase drivers and the vfp driver. When I choose the driver, Word opens up with the correct field information, but without menus or toolbars, and no way that I've found to make them reappear.
>
>In word, in the options (General), "Confirm Conversion at Open" is unchecked.
>
>On a hunch, I used the ODBC Administrator to delete the user DSNs that used the dBase driver. Leaving only the Visual Fox driver as a user DSN choice for '.dbf' files.
>
>Now it works flawlessly.
>
>Can anyone shed any light on this? I doubt I can go to our clients and tell them to do what I did. In my case it didn't matter since I don't have anything on my system (that I know of) that would need a dBase ODBC User DSN.
>
>Much appreciated.