If each user is going to SDETACH and SDISCONN the table when they are done with it then it should be SATTACHED as a Temporary table.
The reason is if 3 users all want to use the SATTACHED table no problem. When SCONNECT and SATTACH executes if the SATTACHED table already exists it will be ignored. So all are working. User 1 is finished with the SATTACH table. The code then executes the SDETACH. The problem is the other 2 users also lose the SATTACHED table. Buddy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Emmitt Dove Sent: Friday, May 15, 2009 10:36 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DSNless connection Buddy, While that does work - today, anyway - you need to ask whether it is good practice to assume it will continue to work. Emmitt Dove Manager, Converting Applications Development Evergreen Packaging, Inc. [email protected] (203) 214-5683 m (203) 643-8022 o (203) 643-8086 f [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Walker, Buddy Sent: Friday, May 15, 2009 9:42 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DSNless connection Jim This would work provided everyone is able to SCONNECT in the same manner. I do this a lot using the DSNless connection. I don't SDETACH the table so when anyone using the SATTACHed table it automatically reconnects. Buddy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jim Belisle Sent: Friday, May 15, 2009 8:52 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DSNless connection EMMIT, Here are the two databases I use: LABOR & SALES. The LABOR DB is my primary database. I created a Menu that is brought up with the DAT file so they have access to all the forms they need. My sales people need to connect to one table (LEADALL) in the SALES database on a regular basis. This one table has all the leads and we use the Indexed field (LEADCODE) to bring up the customer information when they call for either a quote or want to order items. As you can see, the potential for being used constantly is very real. My question to you is this: If they SALES database is disconnected, will they still be able to access the table (LEADALL) information? Jim -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Emmitt Dove Sent: Friday, May 15, 2009 7:44 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DSNless connection Jim, My advice is to only create the connection to the other database when you need it, then drop it as soon as you can. As an example, we write inventory audit records into one of three external audit databases (dependent on the inventory type). Those audits are created by triggers on the inventory tables. In the stored procedure that is the trigger we do the SCONNECT, write the record(s), then SDISCONNECT. This avoids having umpteen people holding each of those audit databases open constantly - they are only open when required. You can SCONNECT the database, create your SATTACH, then SDISCONNECT; the attached table definition remains in your main database, so any other structure elements that refer to it remain sound (i.e. views). Why do it this way? Each client has fewer resources in use (file handles), and with files on the server not held in an open state needlessly, there are just fewer things that can go wrong, fewer ways your databases can become corrupted through external means. I've had situations where a client machine crashed, and I had to reboot the file server to release the open files. Plus, since you don't have other users constantly connected to the target database, you can, if you need, connect it with MULTI OFF briefly to make a quick structure change, such as add an index. Emmitt Dove Manager, Converting Applications Development Evergreen Packaging, Inc. [email protected] (203) 214-5683 m (203) 643-8022 o (203) 643-8086 f [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jim Belisle Sent: Friday, May 15, 2009 6:04 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DSNless connection Razzak, Thanks for the reply. I did check all the settings as you suggested and all looks good. I read the documentation you suggested below as well prior to setting up the ODBC connection. I have tested it and it works for me. Hopefully there will be no "bugs" to work out. Jim -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of A. Razzak Memon Sent: Thursday, May 14, 2009 11:44 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DSNless connection At 08:22 PM 5/14/2009, Jim Belisle wrote: >RBASE is set up on each individual computer but the database is >set up on a server. If I put a DSN less connection to another >RBASE database in the DAT file for when each user starts up, will >that be a problem? Will there be a conflict in this scenario? >We use the latest 7.6. Jim, Using System DSN or DNS-Less connection, you will have to make sure that a full version of R:BASE 7.6 for Windows is installed using the full installer that installs and configures the R:BASE 7.6 ODBC driver. Use the ODBC Data Source Administrator panel to verify the properly installed R:BASE 7.6 ODBC Drivers. ODBC Data Source Administrator | Drivers ... R:BASE 7.6 ODBC driver should be list as follows: Name: R:BASE 7.6 Database Driver (*.rb1) Version: 7.06.07.3xxxx Company: R:BASE Technologies, Inc. File: RBG76_32.DLL Date: mm/dd/2009 Once the R:BASE 7.6 ODBC driver is installed and configured, you should be able to use the DSN-Less connection to SCONNECT and SATTACH tables as server or TEMPORARY table(s) from another R:BASE database. Here is an example to automate the entire process: -- Assure the connection of primary database IF (CVAL('DATABASE')) <> 'primrydb' OR (CVAL('DATABASE')) IS NULL THEN CONNECT primrydb IDENTIFIED BY NONE ENDIF -- Make sure that previously SATTACHed table is detached SDETACH ALL NOCHECK -- Make sure that the previously DSN-Less Database is Disconnected SDISCONNECT ';Driver=R:BASE 7.6 Database Driver (*.rb1);dbq=seconddb' -- Now Connect the Database Using the DSN-Less Connection SCONNECT ';Driver=R:BASE 7.6 Database Driver (*.rb1);dbq=seconddb' -- SAttach Table(s) SATTACH table1 AS ttable1 USING ALL SATTACH table2 AS ttable2 USING ALL SATTACH table3 AS ttable3 USING ALL -- do what you have to do after SATTACHing R:BASE database tables -- Prior to exiting the application, make sure that all SATTACHed -- table(s) are detached and the DSN-Less Database is Disconnected SDETACH ALL NOCHECK SDISCONNECT ';Driver=R:BASE 7.6 Database Driver (*.rb1);dbq=seconddb' For a technical document with further details, take a look at: From The Edge: http://www.razzak.com/fte/ Article: Using DSN-Less Connections in R:BASE Very Best R:egards, Razzak.
