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
