>>Hi Cetin,
>>
>>>To my experience, there is not a problem with using bookmarks or document variables or merge fields.
>>>It is however a problem if you are instantiating word using getobject() instead of creatobject().
>>
>>I first attempt a getobject() and if that does not return anything, I do a createobject(). I coded this about 10 years ago and I think I did that because, if I remember, there is a fair bit of bloat on the users machine if you create a new instance every time - can't find a note to confirm this but I think that was the reason I did this.
>
>OK, then that explains the errors. Stop using GetObjects() and your problems should end (use a local variable for the word object and be sure it is released as soon as it is used).
>
>
>>
>>>My favorite is mergefields. You simply set the data and do the merge to a destination. Bookmarks work quite nicely too, provided you check existence of bookmark before attempting to set it. But it is for a single document (mailmerge can output N documents from a single template in a single shot). >Same with document variables.
>>
>>>PS: I wonder what reasons might be given against mergefields.
>>
>>Re-reading the chapter in the book, the only reason "against" mergefields is the fact that you have to have ODBC set up on the client machine to attach to a data source - and the potential problems with that. They then recommend to instead create the datasource on the fly via setting up a table in a new document (if I follow them correctly) and then programatically attaching that data to the main document. Or at least it seems that way. The code in their book seems fairly straightforward.
>
>" you have to have ODBC set up on the client machine to attach to a data source" I would disagree. I posted here a few times I believe, mailmerge samples, not using ODBC but VFPOLEDB. Even if, suppose you can't directly connect to VFP data, you can simply create a txt file as a 'data source', or directly write to a mailmerge documents' data document.

Yeah, we wrote the book in 1999 and 2000.

Tamar