APD connect manually only

[Cornelius.Eckhoff]

Hello,

I just want my ADP not to connect on startup. Normally when opening the
xx.adp-file Access tries to connect automatically.

Is there any option, trick, workaround? I found a source to reconnect
or change the connection via vba code, now I want to prohibit Access to
start a connection on startup as this takes too much time.

Thanks in advance!

[Lyle Fairfield]

Co***************@Web.de wrote:

Hello,

I just want my ADP not to connect on startup. Normally when opening the
xx.adp-file Access tries to connect automatically.

Is there any option, trick, workaround? I found a source to reconnect
or change the connection via vba code, now I want to prohibit Access to
start a connection on startup as this takes too much time.

My experience with ADPs is that they open quickly unless the connection
errors out, not being able to find the Server, Database, or having
problems with User ID or Password. This can take forever.

In any case, why would connecting through code be faster than default
connecting?

The Connection Objects made available to us through VBA are copies of
the ADP's Connections. We can close or disonnect these copies, but this
has no effect on the information used to connect; it persists. We can
cause this information to change by reconnecting or changing the
connection, but the persisted information is simply replaced by our new
information.

We could create a new ADP, not connect it to anything, import all the
objects from the old ADP; then we would have what you want. But as soon
as we established a connection, the connection information would
persist and at next Open, the ADP would try to connect.

I have experimented with ADPs with no connection (never had a
connection) using ADO recordsets (with their own ADO connections having
nothing to do with the project other than they are created in code) for
forms and reports. In my opinion, because of Security concerns, these
are the only kind of ADPs that should be used in a situation where any
data on the Server is important or crucial and where there are users
beyond me. These ADPs are completely capable and, actually pretty
wonderful applications. To some extent they combine the joys of bound
and unbound. But development time is expanded by a factor of at least
two for me and I am a experienced coder and a experienced ADP
developer. For others the factor might be more, or things might not
work at all.

My guess is that it is not your connection which is taking so long at
startup. I would suggest that you carefully examine everything you do
at startup to see if there is not something else that is slow. Errors
can be problematic when code handles them; sometimes Access will churn
for a long time before it decides to move on.

[Cornelius.Eckhoff]

Thanks for your reply!

You are right, the best possibility would be to make the whole
conection stuff separately and have no default connection.
Why I wanted that solution is, that sometimes the server is down.
Opening the application then ends in a frozen application. (But this
behaviour is not normal, I played with a test ADP and it opened
although no server present.)

In addition I want to give my customer the ability to switch from test
to plan or productive system.

Sincerely

Cornelius

Lyle Fairfield schrieb:

Co***************@Web.de wrote:

Hello,

I just want my ADP not to connect on startup. Normally when opening the
xx.adp-file Access tries to connect automatically.

Is there any option, trick, workaround? I found a source to reconnect
or change the connection via vba code, now I want to prohibit Access to
start a connection on startup as this takes too much time.

My experience with ADPs is that they open quickly unless the connection
errors out, not being able to find the Server, Database, or having
problems with User ID or Password. This can take forever.

In any case, why would connecting through code be faster than default
connecting?

The Connection Objects made available to us through VBA are copies of
the ADP's Connections. We can close or disonnect these copies, but this
has no effect on the information used to connect; it persists. We can
cause this information to change by reconnecting or changing the
connection, but the persisted information is simply replaced by our new
information.

We could create a new ADP, not connect it to anything, import all the
objects from the old ADP; then we would have what you want. But as soon
as we established a connection, the connection information would
persist and at next Open, the ADP would try to connect.

I have experimented with ADPs with no connection (never had a
connection) using ADO recordsets (with their own ADO connections having
nothing to do with the project other than they are created in code) for
forms and reports. In my opinion, because of Security concerns, these
are the only kind of ADPs that should be used in a situation where any
data on the Server is important or crucial and where there are users
beyond me. These ADPs are completely capable and, actually pretty
wonderful applications. To some extent they combine the joys of bound
and unbound. But development time is expanded by a factor of at least
two for me and I am a experienced coder and a experienced ADP
developer. For others the factor might be more, or things might not
work at all.

My guess is that it is not your connection which is taking so long at
startup. I would suggest that you carefully examine everything you do
at startup to see if there is not something else that is slow. Errors
can be problematic when code handles them; sometimes Access will churn
for a long time before it decides to move on.