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
