We used to have an issue similar to yours where (after a crash) the database was unavailable to all users until the one original "Crashed" session was disconnected from the server.
We found that a server reboot was not necessary. It appeared to us (really just a guess) that the rx1 or rb1 file was locked by the Server 2008 operating system. 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. -- Below is another issue we resolved but don't completely understand after moving to Server 2008, it is similar to the post by Bob Thompson: We have approx 35 Citrix/RDP sessions running on Two Citrix/RDP running 2008 using a Citrix Access Gateway to balance the load. We found that after we went to Sever 2008 (from 2003) that ocassionaly the users were unable to load a compiled exe after a user had logged out. The error was "unable to load application". We found that this only happened when user 0 logged out and it appeared that the drive mapping had been removed from all currently attached users. At first we would login first on each server to reserve user 0 and not log out all day. We were finally able to work around this issue by installing the compiled exes to each of our two Citrix/RDP servers on a local directory, instead of mapping to the exe located in the shared database directory on a different 2008 server. Our research pointed to a Windows issue stating that RDP only uses one MCB (Master Control Block) for all users? (Trust me, I don't totally understand this issue). So know I have three copies of each exe I must replace each time I recompile. Since we mapped the exe local to the Citrix/RDP server the system has been very stable. Moving from Sever 2003 to 2008 was quite an experience. Kenny Camp From: [email protected] [mailto:[email protected]] On Behalf Of jan johansen Sent: Tuesday, October 18, 2011 11:01 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Hanging terminal server sessions? I don't know if this will help. In the past month, 9.1 was changed to have the scratch files ($$$) changed from an 8 character file to a GUID 32 character file (I think). I believe the reason was because of network collisions over duplicate scratch files. -----Original Message----- From: Lawrence Lustig <[email protected]> To: [email protected] (RBASE-L Mailing List) Date: Tue, 18 Oct 2011 08:55:24 -0700 (PDT) Subject: [RBASE-L] - Re: Hanging terminal server sessions? Thanks Bob. I don't believe there are any ODBC connections in this system (I recall writing an R:Base-to-R:Base ODBC thing for them years ago but I believe it's rarely if ever used). Is the Windows RDP profile temp folder different from setting SCRATCH to TMP? How do you get this folder from the environment? When you saw this problem was it sporadic? The report I have is sporadic -- sometimes once a week, sometimes several times a day. But the system does run most of the time. -- Larry _____ From: Bob Thompson <[email protected]> To: RBASE-L Mailing List <[email protected]> Sent: Tuesday, October 18, 2011 10:54 AM Subject: [RBASE-L] - Re: Hanging terminal server sessions? Larry, I experienced the very same symptoms a couple of years ago, running 7.5 compiled. I was able to resolve my issue, however I modified more than one possible cause, so I'm not 100% sure which fixed it. So I will list what I did and perhaps, where applicable, one might help. ODBC connections: My database had several ODBC connections to non-Rbase tables. Some of these were originally attached without a "using" clause. This resulted in all columns being a "Qualkey" link in these tables. I corrected this to have only one QualKey column. I also changed code to DisConnect ODBC connections after use where ever I could, not leaving them open "all day" Temp files: I originally was using a shared TEMP folder for all RDP user's $$$ files. I changed the code to use the user's Windows RDP profile temp folder. I set the RDP user's rights to full for the shared Database folder. (This added erase authority, but I was grasping for solutions) Compiled file: I had about 20 RDP sessions running from 1 shared folder and compiled .exe. I made 4 duplicate folders and went to about 5 users per .exe. This might seem strange, but I had reasons to suspect some odd trerminal server issue running so many copies of the same exe. Anyway, after the above, my issue went away. I could introduce one back in at a time, but the system is working great and I do not have the time for that luxury. I suspect the ODBC changes were probably causing my iisues, but it could have been any of the above. Good luck. Bob Thompson LaPorte, IN 219-363-7441 Sent from my iPod On Oct 18, 2011, at 8:07 AM, Lawrence Lustig < [email protected] <mailto:[email protected]> > wrote: A client has recently started having problems with their R:Base system "hanging" -- all attached sessions stop running and the database files become unavailable until the server is rebooted. I believe that the onset of this problem more or less coincides with their changing some machines in their facility from networked workstations to thin clients attaching to RDP sessions. I'm wondering if dropped or incorrectly terminated RDP sessions could account for the sudden onset of problems they're seeing. Does anyone have an experience with this? -- Larry
