I found what I considered to be a bug in ADOX and therefore stopped using it.

The exact details as far as I remember were as follows.

As far as ADOX is concerned a SELECT query with no parameters was considered to be a VIEW. An action query or a SELECT with parameters was considered to be a PROCEDURE.

I was using ADOX to try and modify a QueryDef. The query should have been a view but the view collection said it didn't exist. Great, the Proc collection said it contained the query, but when I tried to edit it and save it I got a message basically saying that although it was in the proc collection it was a view.

I found DAO to be more stable and faster and so gave up on ADO within Access.

On the subject of linked tables, the problem is that you have to be very careful how much data you bind to your controls. Access gives all encompassing functionality to bound data and it is this that causes the locking problems.

The idea of limiting what is brought back from SQL to display on a form is basic good practice.

One of the problems I had when I first switched to VB was how to get the functionality that was standard in Access within my VB app. It wasn't long before I worked out that a completely different design approach was needed and that a VB front end to an Access database allowed far greater concurrency than an Access front end to an Access data file.