Important Access Client/Server tip

[Steve Jorgensen]

I just got paid to solve this problem for one client, so I might be impeding
future business opportunities by sharing this secret, but a rising tide floats
all boats, so... I've seen this mysterious problem now in many Access C/S
applications. Usually some random GUI or workflow changes make the problem,
but for at least one of my clients, the problem was chronic.

You have an Access form bound to a linked SQL Server table. You try to save a
record from Access, and it hangs, possibly timing out with an error
eventually, or possibly until you kill Access or kill the connection from the
server-side (regardless of the timeout setting in Access). During this
lock-up, there is one SQL Server process blocking another - both intiated from
the same client workstation. The problem is usually intermittent, and hard to
reproduce.

Of course, if the 2 processes were blocking each other on the server-side, SQL
Server would detect that as a deadlock, and pick one of them to fail, but in
this case, it turns out we have process A (a SELECT query returning rows to
Access) blocking process B (an update) on the server, and Access hanging
waiting for process B before it will continue reading rows from process A,
thus allowing A to complete and stop blocking process B.

It turns out that process A is always the query for a combo box or list box,
and the answer turns out to be to always force combo and list boxes to
populate completely by reading the ListCount property immedately on form load,
and after every time a combo box is requeried or has its rowsource changed.
Presto - problem solved.

[Rick Brandt]

Steve Jorgensen wrote:

I just got paid to solve this problem for one client, so I might be
impeding future business opportunities by sharing this secret, but a
rising tide floats all boats, so... I've seen this mysterious
problem now in many Access C/S applications. Usually some random GUI
or workflow changes make the problem, but for at least one of my
clients, the problem was chronic.

You have an Access form bound to a linked SQL Server table. You try
to save a record from Access, and it hangs, possibly timing out with
an error eventually, or possibly until you kill Access or kill the
connection from the server-side (regardless of the timeout setting in
Access). During this lock-up, there is one SQL Server process
blocking another - both intiated from the same client workstation.
The problem is usually intermittent, and hard to reproduce.

Of course, if the 2 processes were blocking each other on the
server-side, SQL Server would detect that as a deadlock, and pick one
of them to fail, but in this case, it turns out we have process A (a
SELECT query returning rows to Access) blocking process B (an update)
on the server, and Access hanging waiting for process B before it
will continue reading rows from process A, thus allowing A to
complete and stop blocking process B.

It turns out that process A is always the query for a combo box or
list box, and the answer turns out to be to always force combo and
list boxes to populate completely by reading the ListCount property
immedately on form load, and after every time a combo box is
requeried or has its rowsource changed. Presto - problem solved.

You can also specify NO LOCK if using a pass-through for the List/Combo and
that will also prevent the problem.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Steve Jorgensen]

On Tue, 15 Feb 2005 15:44:15 -0600, "Rick Brandt" <ri*********@ho tmail.com>
wrote:

Steve Jorgensen wrote:

I just got paid to solve this problem for one client, so I might be
impeding future business opportunities by sharing this secret, but a
rising tide floats all boats, so... I've seen this mysterious
problem now in many Access C/S applications. Usually some random GUI
or workflow changes make the problem, but for at least one of my
clients, the problem was chronic.

You have an Access form bound to a linked SQL Server table. You try
to save a record from Access, and it hangs, possibly timing out with
an error eventually, or possibly until you kill Access or kill the
connection from the server-side (regardless of the timeout setting in
Access). During this lock-up, there is one SQL Server process
blocking another - both intiated from the same client workstation.
The problem is usually intermittent, and hard to reproduce.

Of course, if the 2 processes were blocking each other on the
server-side, SQL Server would detect that as a deadlock, and pick one
of them to fail, but in this case, it turns out we have process A (a
SELECT query returning rows to Access) blocking process B (an update)
on the server, and Access hanging waiting for process B before it
will continue reading rows from process A, thus allowing A to
complete and stop blocking process B.

It turns out that process A is always the query for a combo box or
list box, and the answer turns out to be to always force combo and
list boxes to populate completely by reading the ListCount property
immedately on form load, and after every time a combo box is
requeried or has its rowsource changed. Presto - problem solved.

You can also specify NO LOCK if using a pass-through for the List/Combo and
that will also prevent the problem.

Where do you specify NO LOCK? Specifying "No Locks" on the form definitely
does not help.

[John Winterbottom]

"Rick Brandt" <ri*********@ho tmail.com> wrote in message
news:37******** *****@individua l.net...

Steve Jorgensen wrote:

You can also specify NO LOCK if using a pass-through for the List/Combo
and
that will also prevent the problem.

I can see two potential problems with using a NO LOCK hint. First, it's only
supported by SQL Server. Second, the resultset becomes read-only - so you
can't re-use the same procedure for a records-updating function later on.

Although it involves writing more code i think a better way might be to use
callback functions and a forward-only recordset to populate lists and combo
boxes.

[Steve Jorgensen]

On Tue, 15 Feb 2005 19:30:36 -0500, "John Winterbottom" <as******@hotma il.com>
wrote:

"Rick Brandt" <ri*********@ho tmail.com> wrote in message
news:37******* ******@individu al.net...

Steve Jorgensen wrote:

You can also specify NO LOCK if using a pass-through for the List/Combo
and
that will also prevent the problem.
I can see two potential problems with using a NO LOCK hint. First, it's only
supported by SQL Server. Second, the resultset becomes read-only - so you
can't re-use the same procedure for a records-updating function later on.

Ah - the lock hint. That may be OK because I've never seen this symptom with
other back-ends (only tried PostgreSQL), and the lock hint would be used in
stored procedures, so the results are read-only anyway with an MDB front-end.
Although it involves writing more code i think a better way might be to use
callback functions and a forward-only recordset to populate lists and combo
boxes.

Hmm - I had thought of that, and dismissed it as overengineering since getting
the ListCount works. Thinking more about it, though, I guess it doesn't
require any support code in the forms like the ListCount approach does, and is
not prone to code omission later.

[Trevor Best]

Steve Jorgensen wrote:

Although it involves writing more code i think a better way might be to use
callback functions and a forward-only recordset to populate lists and combo
boxes.

I find callback functions painstakingly slow to populate a combo box,
the only time I've used them in the past is to poplate lists of tables
or forms in the database, it may be just that. But the thing is when
using the type down facility it appears to be running all that callback
code again and again. I've changed all those combos to now use a temp
table in the front end and populate that on form load, much improved.
Hmm - I had thought of that, and dismissed it as overengineering since getting
the ListCount works. Thinking more about it, though, I guess it doesn't
require any support code in the forms like the ListCount approach does, and is
not prone to code omission later.

I generally call a common function in the open event of every form,
something that then calls the ScaleForm from ADH so I'd put a common
function there to loop and do all combos. Only problem would be when
requerying later on.
--
This sig left intentionally blank

[Steve Jorgensen]

On Wed, 16 Feb 2005 08:17:48 +0000, Trevor Best <no****@besty.o rg.uk> wrote:

....

Hmm - I had thought of that, and dismissed it as overengineering since getting
the ListCount works. Thinking more about it, though, I guess it doesn't
require any support code in the forms like the ListCount approach does, and is
not prone to code omission later.

I generally call a common function in the open event of every form,
something that then calls the ScaleForm from ADH so I'd put a common
function there to loop and do all combos. Only problem would be when
requerying later on.

That's exactly what I am doing, and that's exactly the problem. Someone has
to search the app for cases of combo box requerying and rowsource assignment,
and fix each one. Then, everyone has to remember from then on to do the same
for any new cases that are introduced.

At least I was able to automate the process of inserting a call to a procedure
that fills all combo boxes on a form into the Form_Load handler of any form
that doesn't already have the procedure call.

[Rick Brandt]

Steve Jorgensen wrote:

On Tue, 15 Feb 2005 15:44:15 -0600, "Rick Brandt"
<ri*********@ho tmail.com> wrote:

You can also specify NO LOCK if using a pass-through for the
List/Combo and that will also prevent the problem.

Where do you specify NO LOCK? Specifying "No Locks" on the form
definitely does not help.

In a pass-through query to a SQL Server.

SELECT FieldName
FROM TableName (NOLOCK)

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Rick Brandt]

John Winterbottom wrote:

"Rick Brandt" <ri*********@ho tmail.com> wrote in message
news:37******** *****@individua l.net...

Steve Jorgensen wrote:

You can also specify NO LOCK if using a pass-through for the
List/Combo and
that will also prevent the problem.
I can see two potential problems with using a NO LOCK hint. First,
it's only supported by SQL Server. Second, the resultset becomes
read-only - so you can't re-use the same procedure for a
records-updating function later on.

Why would I care if the query used to populate a ListBox or CombBox was
editable?
Although it involves writing more code i think a better way might be
to use callback functions and a forward-only recordset to populate
lists and combo boxes.

I did this in a couple of cases where I was using a larger list to populate
the control than I am ordinarily comfortable with. If the list of rows is
small the entire set is likely to be pulled initially anyway. A Call-Back
on such a large set would perform terribly. Also the reason I don't like
the RowCount solution. It solves the problem by forcing all of the rows to
be pulled over the network. I see no reason to do that if I don't have to

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Steve Jorgensen]

On Wed, 16 Feb 2005 09:04:14 -0600, "Rick Brandt" <ri*********@ho tmail.com>
wrote:

John Winterbottom wrote:

"Rick Brandt" <ri*********@ho tmail.com> wrote in message
news:37******** *****@individua l.net...

Steve Jorgensen wrote:

You can also specify NO LOCK if using a pass-through for the
List/Combo and
that will also prevent the problem.
I can see two potential problems with using a NO LOCK hint. First,
it's only supported by SQL Server. Second, the resultset becomes
read-only - so you can't re-use the same procedure for a
records-updating function later on.

Why would I care if the query used to populate a ListBox or CombBox was
editable?

Although it involves writing more code i think a better way might be
to use callback functions and a forward-only recordset to populate
lists and combo boxes.

I did this in a couple of cases where I was using a larger list to populate
the control than I am ordinarily comfortable with. If the list of rows is
small the entire set is likely to be pulled initially anyway. A Call-Back

That doesn't match with my experience. One of the cases in which I
experienced the deadlock had to do with a 48-row table.
on such a large set would perform terribly. Also the reason I don't like
the RowCount solution. It solves the problem by forcing all of the rows to
be pulled over the network. I see no reason to do that if I don't have to