Very Computer

I have an application in Access97 that uses RAS/DUN to connect to an SQL
server and perform some insert and select queries.  After disconnecting
the Dial Up Networking on the Cleint, the session on the Server
(6.5) stays open for an extremely long time (over 30 Minutes most of the
time).  Under the session are two processes.  Details follow:
        1.      Set implicit_transactions Off
        2.      SELECT Name, Address, etc... FROM tblMainInfo

I am having a problem running out of valid connections until these clear
out.  Should these connection drop soon after the last SQL statement was
sent?  How long should these sessions remain open?

Any help is appreciated,
Terry Lowe
AI

I seen something like this here .
with Access 2.0 the queries may stay active until the user closes Access,
but will always disconnect when the user turns off there computer.

what need to be done is convince the DB that the user is gone.
it sounds like the DB connection is being keep open by something , try:

1) in the File Exit script , issue a Disconnect from the DB and see if this
closes the connection.
or
2) (i'm not sure where to look for this) Check the time out value for this
connection (either in Access or SQL) and reduce it (watch out for a value
that is to low and stop the queries from running)
or
3) check you RAS settings at the host (expectly the Time/out or disconnect
settings) this may be keeping the link from the DB to the RAS open even if
there is no one on the other end, you might what to issue a reset device on
disconnect ( if such an option exists ).  ****This is where I think the
problem is.****

HTH
Tim - OMG

Normally they will go.

However, I notice that the last thing you do is a select, you can get a
situation where the client has ran a query and SQL Server is returning
results, at some point the client bombs and SQL Server gets confused and
thinks the client is still there, SQL Server then waits for the client to
tell it to send more results, of course the client won't because it's not
there anymore.

You can tell if this is occurring by looking at master..sysprocesses, the
connections will have a waittype of 0x0800 and quite probably won't be
killable.

The only thing I can suggest is that you wait a bit longer before dropping
the RAS connection.

--
Tony Rogerson
Torver Computer Consultants Ltd.

begin 666 Tony Rogerson.vcf
M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..E)O9V5R<V]N.U1O;GD-"D9.


M3U1%1"U04DE.5$%"3$4Z.SM4;W)V97(],$0],$$R-B!-;V]R;&%N9"!2;V%D
M.TAA<G!E;F1E;CM(97)T9F]R9'-H:7)E.T%,-2 T3$$[16YG;&%N9 T*3$%"
M14P[5T]22SM%3D-/1$E.1SU154]4140M4%))3E1!0DQ%.E1O<G9E<CTP1#TP
M03(V($UO;W)L86YD(%)O860],$0],$%(87)P96YD96XL($AE<G1F;W)D<VAI

M150Z=&]N>7)O9V5R<V]N0&-O;7!U<V5R=F4N8V]M#0I2158Z,3DY.# W,314

`
end

Quote:> Normally they will go.

> However, I notice that the last thing you do is a select, you can get a
> situation where the client has ran a query and SQL Server is returning
> results, at some point the client bombs and SQL Server gets confused and
> thinks the client is still there, SQL Server then waits for the client to
> tell it to send more results, of course the client won't because it's not
> there anymore.

> You can tell if this is occurring by looking at master..sysprocesses, the
> connections will have a waittype of 0x0800 and quite probably won't be
> killable.

> The only thing I can suggest is that you wait a bit longer before dropping
> the RAS connection.

> --
> Tony Rogerson
> Torver Computer Consultants Ltd.

That seems to be the crux of the problem.  If I open a pass through
query, and leave it open, then diconnect RAS I get the result that I
first posted about.

I'll try extending the RAS disconnect time and see what happens.

Thanks,
Terry Lowe