In a 7.6 compiled, an un-reproducible occasional problem (access violation) became more of a problem after we took the plunge to move into 9.1 for our live operations. But because of the upgrade to 9.1, we finally discovered a way to reliably replicate the issue. Even though it no longer gave an access violation, it would still "freeze" the application. Once it could be replicated, I kept removing code and object from the form until only a few objects and a few lines of code remained and discovered the offending line of code.
Thanks to the decision to move ahead with 9.1, and the resulting unintended consequences, and with RBase Technologies support, we were able to resolve a problem I had been perplexed by for months back in 7.6. My code was using a view to combine three very active tables to test for existence of data (including a where limit = 1), and then enable or disable a button that could create a full report. I rewrote the code to do a direct look at the one table that was really necessary, and eliminated the view from the "test for any data" code. The same view is always successful when used to create a report, but would fail during the busiest times of activity. I could never get it to crash in single user tests, or in limited 9.1 testing before the rollout. Problems only appeared when the database (these particular tables) were very busy in live operations. Somehow, while I was originally optimizing speed of this "part history lookup form", I overlooked this particular bit of lookup code. Probably because the tables remain very small (even though there are a lot of writes and deletes), no speed improvement seemed possible, so I had left the clumsy line of code. Since I improved this one line of code, the problem has not reappeared. We have not determined the exact nature of why this was happening, but we have had several issues that appeared only after we moved all of our servers (file servers and Citrix/RDP servers) to MS Sever 2008 from 2003. It's only a guess, but it seemed to me like many RBase sessions were competing for access to the RX1 file, and operating system file locks may have been an issue. I have changed my programming habits to use more temp tables and other methods to deal with this" UNPROVEN AND POSSIBLY TOTALLY INCORRECT" theory. Management was so pleased with the improved operations, they hired more salespeople and are working the system even harder now. I am pleased because I sleep better at night. :-) Kenny From: [email protected] [mailto:[email protected]] On Behalf Of Lawrence Lustig Sent: Tuesday, October 25, 2011 7:53 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Hanging terminal server sessions? << After a great deal of testing and hunting, I found the offending code, rewrote, and this problem has not returned since. The offending code would work 99% of the time, and appeared to only create a problem when the database was under very heavy usage by a large number of users. >> Two questions: 1. How did you hunt down the problem piece of code? 2. What was the nature of the code that was causing the problem? Thanks! -- Larry
