The usual way to check this is to try to open the file with exclusive
locking and then ascertain after the event whether you actually *do*
have exclusive locking. This is easy when Excel is automated (e.g.
using VBA Open keyword).

However, I don't know of a reliable way of doing the same using ADO.
You can attempt to get exclusive locks on the connection i.e.

XLconn.Mode = 12 ' adModeShareExclusive

and apparently get it even if the when the workbook is open i.e. no
run-time errors and no ADO errors. You can then open a recordset with
pessimistic locking e.g.

rs.LockType = 2 ' adLockPessimistic

and apparently get that too i.e. no errors.

It's only when you try to do something which requires exclusive
locking that the truth emerges e.g.

XLconn.Execute "CREATE TABLE DropMe (Col1 INT)"

when an error occurs.

--

"nate axtell" <naxtell at progeny dot net wrote in message ...
Yes, the the Jet driver gives the same problem.

"onedaywhen" wrote in message
om...
Have you tried using the JET OLE DB provider i.e.

XLconn.ConnectionString = "Source=" & FileName & _
";Extended Properties='Excel 8.0'

--