The only other suggestion I can make may not be feasible in your
situation, and that is of course that if you have split
forms/macros/code into a separate front end and data into a separate
back end, then maybe there is not such a problem in this area.
It may be worth asking a new question in an access group about the whole
issue of what exactly Access is locking that causes other stuff to fail
- I certainly don't have the experience with Access to have much of a
clue other than what I have already said.
Peter Jamieson
http://tips.pjmsn.me.uk
On 22/02/2010 13:45, InvisibleDuncan wrote:
According to a trawl of the net, it would seem that the reason for the error
I get when trying to use OLEDB (the "dialog or database engine" error) is
that my database, although not opened exclusively, does something that makes
it act as if it's open exclusively, and it therefore prevents Word from
accessing it. I think that probably fits in with what you're saying. The
advice was to open it again from within the Access code itself (doing a
Connection.Open), as that would force it to be opened in shared mode. Sadly,
it doesn't work for me.
I get the same error when using your minimalist version of the connection
string, too.
"Peter Jamieson" wrote:
Something that I have never understood is that sometimes when you have
the Access VBA Editor open, or run Access VBA code, Access seems to put
the database in a state that makes connections from Word fail. Ten
minutes later you can run the same code and it works fine. I can only
assume that it has something to do with the locking and/or timeout
options in Access Tools-Options-Advanced. Or perhaps it's just some
simple thing I'm failing to do, like stop debugging or some such.
It isn't something I have explored in depth, but it's exactly what just
happened when trying to replicate your problem. BTW, I was able to
connect via OLEDB using the minimalist
objDoc.MailMerge.OpenDataSource _
Name:=CurrentDb.Name, _
sqlstatement:="SELECT * FROM [Table1]"
Peter Jamieson
http://tips.pjmsn.me.uk