>>Thanks Cetin,
>>I'm not sure how this happens, but If I go into my ODBC drivers and try to configure the Foxpro Driver, it says "This driver is no longer supported, use the Visual Foxpro Driver." Other machines in my office don't do this. I have re-worked my code to use the visual foxpro driver for new documents, but as you suggested, word fails to open the documents created with the old ODBC driver. I get "cannot find installable ISAM". The only way around it is to restore the document to a non-mailmerge document, then save as a new name, then delete the old one and rename the new one back to the original name. Any ideas how I can restore a mailmerge document to a normal document from VFP? My users aren't going to like this! Thanks for your help.
>>
>>Marcus.
>>
>
>Marcus,
>Then try a "nonsmart" way. No ODBC driver is needed :) but works slow :( Actually a few ways, each supplying the data to word :
>1) Save as an xls file and use xls as datasource (no memo support)
>2) Save as SDF, CSV, dlimited etc and use as datasource (no memo support)
>3) Directly write to word mailmerge data doc via datatoclip (no memo support)
>4) Directly write to word mailmerge data doc via scan...endscan (memo support)
>are the ones I can think of for now. Except datatoclip others would be extremely slow but I can assure you it's not VFP's fault.
>Now for an example with no memo support (fastest I think) :

**************************************************
>* Start of code
>**************************************************
>select * from (home()+"samples\data\employee") into cursor wrdTest
>* Replace with your select for invoice
>_VFP.datatoclip(alias(),reccount(),3) && Copy VFP table to clipboard
>PUBLIC oWordDocument
>
>*** set the LOCALEID to English
>nlLocaleId=sys(3004)	&& Save local id
>=sys(3006,1033)			&& We will be sending instructions in English
>wait window nowait "Creating Word Document..."     && Inform user
>oWordDocument=createobject("word.basic")	&& Create word object
>with oWordDocument
>	.appshow	&& Show word app
>	.filenewdefault     && New file, default template - this is our main doc
>	* If you have a predefined doc template
>	* then instead of filenewdefault - fielopen(cTemplateDoc)
>        * Create datasource
>	.MailMergeCreateDataSource(sys(5)+curdir()+"xmergedoc")
>	.MailMergeEditDataSource  && Edit data source
>	.editselectall	&& Select entire doc
>	.editpaste  	&& Clipboard data pasted to word - paste over
>        * Remove spaces - otherwise header fail
>	.editfind(" ","",0,0,0,0,0,0,,1,,1)
>	.editfind("^t^p","^p",0,0,0,0,0,0,,1,,1) && Tab+para to para
>	.editselectall	&& Select entire doc
>	.texttotable(1) && Convert text to table - tabs (1) (Word table)
>	.MailMergeEditMainDocument	&& Activate the main document
>* Now you have "MailMerge" toolbar and at the very left "Insert Merge field tab"
>* You can also insert a merge field programmatically
>* .InsertMergefield("address")
>endwith
>
>**** Set the LocaleId to the previous value
>=sys(3006,val(nlLocaleId))
>
>**************************************************
>* End of code
>**************************************************

This is again w95&w97 compatible word.basic code. VBA code is simplier for you can code it like VFP OOP. I prefer this one for it's compatible between versions.
>Cetin

Thanks again Cetin,
You are very generous with your time. I'm using the new ODBC driver, and re-establishing the mail merge table after opening existing documents. If they error, they can get through the errors, remove all mail merge data, and then the merge is re-established with the new ODBC driver. Still a major irritant for users with 50 or more letters. Oh well, thanks for the work arounds.

Marcus.