Bob,
Heres what we do: 1) With STATICDB OFF, SCONNECT / SATTACH; now the SATTACHed table is defined in the main database and available to all 2) All users run with STATICDB ON, so 1) must be performed by a single user when no one else is connected 3) Normal users do: a. SCONNECT b. Whatever operations are to be performed using the SATTACHed table c. SDISCONNECT The reason for the SDISCONNECT is to release the operating system-level database open on the remote database. As long as a user has an SCONNECT in effect, R:BASE holds the database files open. Even if you dont run with STATICDB ON, the above can/should apply. You only need to SATTACH a table once. There is no harm in leaving it that way. You do not have to SDETACH the table in order to SDISCONNECT. Any SATTACHed tables are visible to all users, UNLESS the SATTACH is performed while STATICDB is ON. In this case, the SATTACH only applies to the user who issued the SATTACH and will go away when the user DISConnects. Emmitt Dove Manager, DairyPak Business Systems Evergreen Packaging, Inc. [EMAIL PROTECTED] (203) 214-5683 m (203) 643-8022 o (203) 643-8086 f [EMAIL PROTECTED] From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, November 17, 2008 3:04 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: SCONNECT / SDISCONNECT 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 dont 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
