Jim,
With STATICDB OFF, do the SCONNECT and SATTACH once. Don't issue SDETACH at all. Then, if you normally operate with STATICDB ON, set it ON and go. This way the SATTACHed table becomes a permanent part of your database schema, even when you SDISCONNECT. Plus, you don't want to have user A attempting to SDETACH the table when user B is editing a record or running a report. With that done, you are then able to SCONNECT then SDISCONNECT at will. Again, I prefer to do this when needed so my users aren't sitting there all day long with the other database(s) open. And certainly not all users require connections to the various ancillary databases. We have four different audit databases (one for each of three different types of inventory) and one for anything related to orders and shipments. We also have a sales history database. If each user had an SCONNECT to each of these other databases because they might do something requiring access to an SATTACHed table, well, that's just too many open files. Thus, the as-needed use of SCONNECT and SDISCONNECT makes sense for us. Now if all your users are going to be frequently accessing an SATTACHed table, it may make more sense to put the SCONNECT in the startup. If you have one group of users, not necessarily all users, who will frequently access such a table, then perhaps a separate startup for them would be a good balance. There's really no one "best" answer - it all depends on your situation. If the way you are doing it works and you aren't having any problems, you probably don't need to change. 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] From: [email protected] [mailto:[email protected]] On Behalf Of Jim Belisle Sent: Monday, June 08, 2009 10:21 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: DSN question Emmitt, I may not have been as clear in my question (previously) as I should have been. The ODBC connection is only needed when entering quotes and the quote form comes up with a bit button EEP. I reread the dialog between Buddy and me (as well as you). Here is the way things are set up: The Form comes up with multiple choices one can make. I have one section made up of a group bar with multiple group buttons. None of these need the ODBC connection. I then have five independent bit buttons I use for entering or editing quotes. Only two of these would need the ODBC connection. Based on what you mentioned to Bob, would it be better to put the SCONNECT and SATTACH in the bit button rather than the DAT file since I only need it for the quote forms? Jim _____ From: [email protected] [mailto:[email protected]] On Behalf Of Emmitt Dove Sent: Monday, June 08, 2009 8:16 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: DSN question Jim, In your case I believe the conclusion was to leave it in the .DAT. I don't recall the specifics, but I do recall coming to that conclusion. 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] From: [email protected] [mailto:[email protected]] On Behalf Of Jim Belisle Sent: Monday, June 08, 2009 6:00 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: DSN question Emmitt, I had this discussion a few weeks back. I thought I would have to put the SCONNECT into the DAT file and that is what I did. What you mention here is putting it into the EEP in the form, is that correct? Jim _____ From: [email protected] [mailto:[email protected]] On Behalf Of Emmitt Dove Sent: Monday, June 08, 2009 1:55 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: DSN question Bob, In 6.5 we had to leave the SCONNECT in place since you couldn't use it in an eep. In 7.x, I adopted the practice of performing the SCONNECT right before it is required and SDISCONNECT immediately afterwards. My thinking is that leaving fewer files open minimizes the opportunity for corruption. As Buddy noted in an earlier exchange, once the SATTACH is performed (and part of your schema), any access of the table will (apparently) perform the SCONNECT without you having to explicitly issue it. I'm not sure we should depend on this always being true, and it also begs the question as to whether the database remains open for the balance of the user's session. I just performed a test, watching Open Files in Computer Management on the server, and it appears that the referenced database remains open until the user leaves R:BASE. 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] From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, June 08, 2009 2:32 PM To: RBASE-L Mailing List Subject: [RBASE-L] - DSN question Almost all of my apps tie in with other software databases. The question I have : A) is it best to SConnect right before I use an ODBC table and then SDisconnect immediately afterwards or B) SConnect at the begining of a session and leave connected until the user logs off. Note that these apps may have 20 users running the Rbase app at a time, all day long and thus have 20 ODBC connections to the foreign database open as well. The ODBC tables will get accessed, depending on which menu option is being run, from only occasionally during the day to rather frequently. Such as every 10 minutes or so. I currently have the apps setup to SConnect at startup of the main Menu and stay connected all day or until the Main Menu is closed. However, I have been running into issues with the foreign ODBC engine locking up occasionally. The only major change in the system is that more people are concurrently using my app and thus more connections to the ODBC driver on the server. (Plenty of memory etc. so that should not be an issue) I am wondering if SConnecting and SDisconnecting "on the fly" would be a better practice or not? I.E. Leave all DSN sources "unconnected" until an ODBC table is needed, SConnect, use the table data, then SDisconnect immediately afterwards. Any thoughts? Thanks, -Bob
