The table size then is a good reason to handle it the way you are (separate database, SCONNECT/SATTACH.) I wouldn't want to be projecting tables that large.
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 10:22 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: DSNless connection Jan, Emmitt, Buddy, I appreciate all the comments on this situation. As is often the case with database questions, there is more than one way to perform the intended task. At present, I have the SCONNECT and the SATTACH code located in the DAT file so the SALES DB and the LEADALL table are connected the minute they bring up the menu. So, Buddy, they all connect the same way. If they get out of the menu during the day, both the DB and the tables are disconnected via a SDISCONNECT and SDETACH code. The SALES DB is not used much during the day and the information in the LEADALL table is updated only periodically, maybe two or three times a week, and that via form entry mode. Your Ideas, Jan and Emmitt, are definitely worth considering since once I set up the PROJECT code you suggested, it would be automatic. The table is quite large, 250,000 rows. As for the speed, since I indexed the LEADCODE column, it is instantaneous. Once again, thanks for the ideas. Jim -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Walker, Buddy Sent: Friday, May 15, 2009 8: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.
