Bob,
I believe that if you are running Client / Server that R:BASE takes over the file access, completely bypassing Windows services, so Windows has no way to know the files are open. I’d still lean toward on-demand connections. 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 6:29 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: DSN question Thanks Emmitt, I too am leaning towards "connecting / disconnecting" the ODBC data source on the fly. Often some of my users are in the application all day long, but may not use the ODBC data source but once or twice. Others use the ODBC tables very frequently. The "Odd" thing about my foreign database is, that Windows Server 2003 does not show any open files to this foreign database via the Manage/Open Files screen. This is a client /server database so I guess the clients never actually open the server files. So I am unsure how leaving an ODBC connection open all day is going to effect the system. Windows Server shows the four Rbase files open by the users, but never any files from the foreign data base. Again, I must assume this is due to the client/server relationship and not the ODBC connection. Some of these users are running the Rbase app over a wireless network connection. Although I never seem to have any issues with dropped connections in my Rbase app, I am wondering if the ODBC connection, not being used for some time, gets cached off on the server or hibernates after some period of time and then the wireless causes some issue. I have definitely tracked my intermittent problem to the foreign ODBC locking up, but have not found the reason why it is doing so. I will try the SConnect/SDisconnect "on the fly" and see if that helps any. Thanks again, -Bob ----- Original Message ----- From: "Emmitt Dove" <[email protected]> To: "RBASE-L Mailing List" <[email protected]> Sent: Monday, June 8, 2009 1:54:39 PM GMT -06:00 US/Canada Central 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
