Thanks Gunnar,
 I will keep this code in mind and have used similar steps.
The question is about the SDISCONNECT.  Do you ever use it in your code at all?
If so, under what circumstance?

Sincerely,
-Bob

--
Thompson Technology Consultants 
LaPorte, IN 46350 
219-363-7441

-------------- Original message -------------- 
From: "Gunnar Ekblad" <[EMAIL PROTECTED]> 

Bob
This snippet of code is stolen with pride from Razzak:

IF vdrive = 'c:' THEN
SELECT COUNT(*) INTO vdsnrows FROM sys_servers WHERE sys_server_name = +
';Driver={Microsoft Access Driver (*.mdb)};DBQ=C:\WASA\Wasaplan.mdb;'
IF vdsnrows = 0 THEN
SCONNECT ';Driver={Microsoft Access Driver (*.mdb)};DBQ=C:\WASA\Wasaplan.mdb;'
ENDIF
ELSE
SELECT COUNT(*) INTO vdsnrows FROM sys_servers WHERE sys_server_name = +
';Driver={Microsoft Access Driver (*.mdb)};DBQ=x:\WASA\Wasaplan.mdb;'
IF vdsnrows = 0 THEN
SCONNECT ';Driver={Microsoft Access Driver (*.mdb)};DBQ=x:\WASA\Wasaplan.mdb;'
ENDIF
ENDIF

I do prefer the DSN-less connection as you can se, please let me know if you 
wants further samples from SATTACH

Gunnar Ekblad
Kontema IT AB
Hästholmsvägen 32
131 30 Nacka
Sweden

-----Ursprungligt meddelande-----
Från: [email protected] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED]
Skickat: den 17 november 2008 20:40
Till: RBASE-L Mailing List
Ämne: [RBASE-L] - RE: SCONNECT / SDISCONNECT

Thanks all.  What I found interesting is the following scenario:

PC #1 SConnects to ODBDC source HFINC and SAttachs to table UPS_Table with an 
Alias of UPSODBC

Do a list table on PC# 2 and the UPSODBC table is listed and you can do a 
select from it.  No pop up about
what ODBC driver source to use is seen.  The table is active and ready.  So the 
SCONNECT must be database
wide.

PC#1 issues a SDISCONNECT  HFINC .  PC# 2 can still select data from UPSODBC as 
well as PC #1.
The SDISCONNECT does not seem to have any effect on either PC.  So I am unsure 
what the SDISCONNECT 
does.

PC #1  issues SDETACH UPSODBC and both PC's no longer list the UPSODBC table.   
 SDETACH is definitely
not user specific. 

So my main question was the SCONNECT statement does not seem to be needed at 
all by other sessions
once one session has SATTACHED to the ODBC table and the SDISCONNECT seems to 
have no effect
on either PC.

I am asking this in that I have been getting a random access violation error.  
I have seemed to isolate it to this
one program that SCONNECTS and SDISCONNECTS to the ODBC database.  Although I 
have not been
able to repeat it at will, I believe it has to do with the SDISCONNECT being 
issued while another session is 
still in the database and attached to an ODBC table.   Although using 2 PC's, I 
have not been able to get the 
SDISCONNECT to seem to make any difference at all on either PC.  I believe I 
will remove any 
SDISCONNECT statements and see if the problem goes away.


-Bob
--
Thompson Technology Consultants 
LaPorte, IN 46350 
219-363-7441

-------------- Original message -------------- 
From: "Walker, Buddy" <[EMAIL PROTECTED]> 
Bob
  Once you SCONNECT and then SATTACH a table anyone using that table must use 
the same type of SCONNECT. For example if you SCONNECT using a DSN and then 
SATTACH sometable. If I want to use sometable then I must have the same DSN on 
my workstation. When I try to use the sometable the SCONNECT is transparent as 
long as I have the same DSN. 

  If a number of users will be using the same SATTACH table then I don’t 
SDETACH it. 

Buddy


From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Monday, November 17, 2008 12:29 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - SCONNECT / SDISCONNECT

This is something I should already know, but did not find a distinct answer in 
my first help search.

Is Sconnect / SDisconnect  session unique or database unique?  I.E.  5 users 
connected to the same database, all five accessing an ODBC table, if one 
session issues a SDisconnect  will this effect the other users?  

During brief testing, it appears that SCONNECT / SDISCONNECT does not effect 
other users, however SATTACH or SDETACH does effect other users.  

If I have a table SATTACHED and issue a SDISCONNECT, the table still functions, 
 it appears the
SDISCONNECT has no impact.  If I SCONNECT and SATTACH an ODBC table in session 
one, session two can access this table and never have to SCONNECT.  So this 
seems to indicate that SCONNECT is database specific and not session specific.  
 However, if I issue a DISCONNECT, it does not effect other users at all.  I 
can Disconnect in session one and session two can still access the table fine.

So my question is, do I need to worry about SCONNECT or SDISCONNECT in a multi 
user environment?  My initial tests seem to say no.?  Certainly SATTACH and 
SDETACH makes a big
difference.

Thanks,
-Bob


--
Thompson Technology Consultants 
LaPorte, IN 46350 
219-363-7441

Reply via email to