Change timeout on an ADO connection object?

I

inews

How can I check or change the timeout property of an ADO connection
object from outside of the application which created it?

I have a third party Access based application (VB front-end) which gets
error 3709 a lot. That means that the connection object is closed or
out of context when the app tries to use it.

I suspect that the connection object is timing out.

If I could somehow read or write the timeout property I might be able
to avoid the errors.
Any utilities or tricks to accomplish this will be gratefully received.
 
I

inews

Thanks Graham.

I understand that and would do it if it were my app.

I have only the compiled executable for the app. How can I do it in
these circumstances?
 
I

inews

If it happens to be declared as a public object, might it be
accessible?

What do you think?

I don't know the name, though, so that would be the first hurdle. Any
way to list all public instantiations of ADO Connectors? There must be
a collection or interface object somewhere in ADO which lists all
current connections...just a simple ObjectID,ConnectionString table so
that when apps contact ADO, ADO then looks up the ObjectID and handles
messages to the relevant ADO object.

Could be in the ODBC driver..........? Just guessing.
Any thoughts?

Sydney, Australia, too.
 
I

inews

If it happens to be declared as a public object, might it be
accessible?

What do you think?

I don't know the name, though, so that would be the first hurdle. Any
way to list all public instantiations of ADO Connectors? There must be
a collection or interface object somewhere in ADO which lists all
current connections...just a simple ObjectID,ConnectionString table so
that when apps contact ADO, ADO then looks up the ObjectID and handles
messages to the relevant ADO object.

Could be in the ODBC driver..........? Just guessing.
Any thoughts?

Sydney, Australia, too.
 
G

Graham R Seach

If it's a public object (like a class), then it's probably instantiated as
PublicNotCreatable, which means you can only use it only after the
application has created it first; you can't create instances of it
externally. That creates its own set of problems, however, I think you'd run
into scope issues anyway, unless the object variable is declared public.

If it's a constant, you have no hope.

If it's a public variable, then we again have scope issues. Since the
frontend is a compiled exe, there are no modules to search through. I don't
like your chances of finding the object/variable without knowing its name.

I would start looking elsewhere for a resolution.

A 3709 error is an application-defined or object-defined error, which could
mean almost anything. It could be a network latency issue, but I think
you're right in this case; I think it probably is an object scope issue, in
which case, you're outta luck I'm afraid.

Just as a test, if you're able to, move the backed onto your local machine,
adn see if that fixes the problem. If so, the start looking at your network.

Since this is a VB issue, not an Access issue, can you not contact the
developer?

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia

Microsoft Access 2003 VBA Programmer's Reference
http://www.wiley.com/WileyCDA/WileyTitle/productCd-0764559036.html
 
D

david epsom dot com dot au

If it is 'Access based' , it shouldn't get ADO time outs: connections
to Jet DB files don't time out. (The timeout property is not enforced
by the ado object wrapper: it is passed to the data provider).

I think you have network problems: Network timeouts will of course
cause connection failures.

(david)
 
I

inews

Two questions: see below for further background
* Separate to this specific problem, what is the most peculiar cause of
a 3709 error you have seen?
* Any thoughts on a possible cause?
=============================

Thanks guys,
that's an interesting point about Access based ADO connections not
timing out, and some interesting points about the likely accessibility
of the connection object.

The MDB file is stored locally, so nothing as simple as putting that
locally, unfortunately.

Have been in touch with the developers with no joy so far.

In the meantime, I have squeezed a debug log out of the app. The
change from being able to use the connection object to being unable to
is subsecond, so timeout now seems unlikely.

The process runs a number of iterations of the same algorithm across
the same data with slightly different inputs each time. Each time
takes 15 minutes and the total run takes about 10 hours. Then the
results are worked over again to produce a second layer of results.
It's at this changeover point that the error occurs. If I specify 10
iterations instead of 40, the 3709 error doesn't occur. Hence the (now
redundant) timeout theory.
 
D

david epsom dot com dot au

The number 3709 is used by ADO and other objects. I don't use
ADO very much, and DAO and Access don't use that number.

Since the problem changes with fewer iterations, is it a
memory leak problem? Can you see memory utilisation changing
as you run the program?

DAO/Jet used to have some problems when you opened and
closed a lot of recordset objects: have the developers
tried running with a dataset as large as yours?

(david)
 
I

inews

Sorry for the late followup David - Christmas, summer holiday etc, etc.

I have passed along a method of replicating the test to the developers,
and they have replicated the problem. They just haven't been able to
fix it.

Yes, memory utilisation creeps higher with each iteration. Any
thoughts on causes of memory leaks?

Would you be kind enough to pass along some details on what those
issues were with opening and closing a lot of recordset objects? Have
there been similar issues in ADO?

Hopefully I can pass along a clue to them that will see the problem
fixed.

Thanks for your help and everyone else's.
Ian
 
D

david epsom dot com dot au

issues were with opening and closing a lot of recordset objects? Have

I don't have any specific references: here are a couple of
related KB articles:

http://support.microsoft.com/kb/q289562/
How to prevent database bloat after you use Data Access Objects (DAO)

http://support.microsoft.com/kb/q197449/
PRB: Problems Reusing ADO Command Object on Multiple Recordsets

But there was also a specific limit on the number of 'table references'
that dao/jet could maintain which, coupled with the failure to release
objects, meant that you hit an arbitrary limit of recordset objects when
looping. There were probably other similar limits as well.

Also a fairly dramatic problem when repeatedly hitting dao/jet errors
in a code loop.

(david)
 
I

inews

Thanks very much.

That second link looks plausible.

I also found an article confirming that access violations can cause
3709 errors, which ties it in a bit more closely.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q198533

I can well imagine that it's an issue with not releasing objects.

Boy, it's a crazy experience trying to debug by remote control like
this. Will post solution if one comes through. Any further thoughts
welcome.
 
Top