The hardware setup in this case is fairly easy to debug. I have a terminal server and a file server. They are connected via a 1 gig managed switch. The two servers sit side by side. 3 foot patch cables connect the switch and the two servers. Both servers and the switch are in a grounded server cabinet and no cables through a wall etc. between the two machines, so there are no issues with external electrical noise. Both servers and switch have fully protected and filtered UPS, so no power issues either.
Since this is happening with the terminal server users, all the hardware is within the one cabinet. Very nice for trouble shooting! The switch logs show no issues, nor does either server event logs. I will change out the patch cables, but do not suspect this is an issue. Two other third party database programs use this equipment heavily and do not show any issues of dropped network connections. I am suspecting it is in how I am running the program via terminal services. All users access the same compiled EXE. Since the scratch files are set to the default temp folder, the temp files for all users are being stored in the same server temp folder. Since I experience the EXE file not releasing in the task maanger at times, I am wondering if I have file lock conflicts on temp files ? Any advise/thoughts as to scratch settings in a terminal service environment and multiple users using the same EXE? Thanks again all, Bob -- Thompson Technology Consultants LaPorte, IN 46350 219-363-7441 -------------- Original message -------------- From: "John Engwer" <[EMAIL PROTECTED]> Bob, does your network have a smart switch? If so, I would check to see if the switch has detected any transmission errors or dropped packets. I believe that the most likely suspects would be a defective NIC , Ethernet wiring issue, or dirty power. All of these can cause intermittent problems across the network. It can be very difficult to isolate this type of problem and it is unlikely that an application that has been running for months or years would suddenly start failing. I have a vertical application that I sell to orthopedic shoe stores. Most of these stores have manufacture/repair facilities that have equipment with large electric motors, electric ovens and other equipment that causes electrical noise and power fluctuations. I am constantly troubleshooting problems that manifest as intermittent errors with my RBASE application. 99% of the time the source of the problem is traced to an infrastructure component. A year or so ago, a client called complaining of hangs (multiple PCs) and we traced it to a defective electric stapler that they plugged in at the sales counter. We found out that the computers in the back office would sometimes hang when they used the stapler at the front counter. We unplugged the stapler and the problems disappeared. Two weeks later someone plugged the stapler back in and the problems returned. Call me if you want to discuss this in more detail. I have been down this road a few times. John 412-751-2433 From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, November 25, 2008 8:33 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Form does not exist I am having issues on a multiuser application where a user will click an EEP on a form that calls another form and they recieve the message: "Form (Form Name) does not exist" (Form Name) is the name of the requested form. The forms all do exist as users run this app 20 hours per day. This does not happen on just one form, but has been seen on any of the 30+ forms in the app. I can click the Exit EEP and this will close the current form out to the main menu form. I click the Exit EEP on the main menu and the session hangs and must be killed in the task manager. I restart the app (no reboot etc.) and the app runs fine, with no errors. It almost acts as if the network connection has dropped, but this is not the case, and I cannot find out why the session hangs on the last EXIT command. Again, this is intermittent and happens only on occasion. But enough that the users are complaining. (Truthfully, a good app should never have repetitive problems, so I take some personal stake in this) One other oddity is that I have 8 users running this app on a terminal server. One user may see this happen and the others continue running without issue. (Thus I know the network connection has not dropped) With the above scenario, it seems fairly clear that this issue is session related and not machine. I.E. one PC running 8 users on terminal service, one user sees the issue and the others not. I have scanned all the EEPS and there are no DISCONNECT or CONNECT commands that would close the current database and as mentioned, the app runs fine except occasionally this pops up. This is a compiled 7.5 app Any thoughts? Thanks, -Bob -- Thompson Technology Consultants LaPorte, IN 46350 219-363-7441
