File open errors

This forum is for eXpress++ general support.
Post Reply
Message
Author
omni
Posts: 531
Joined: Thu Jan 28, 2010 9:34 am

File open errors

#1 Post by omni »

Roger (etal),

We have a new user (fairly new) that has 20 or so users. Now added another 20 via remote access, vpn connect to server, then remote to their remote server.

He is getting errors that just say internal data structure corrupted. No error logs are ever on server, and none added to our error file. Happens at random times.

Today he received a file open error, 3 users attempted to open the file (1 out of 40+ that had already opened) that caused all 3 an error. Retrying worked fine.

No client server is being used. Problem appears to be on the remote access users, as opposed to the local wired users. We have not used the client server in 10 years, basically because we have had no issues and it slows down users, especially opening the app.

Any thoughts are appreciated.

Fred
omni

User avatar
Tom
Posts: 1172
Joined: Thu Jan 28, 2010 12:59 am
Location: Berlin, Germany

Re: File open errors

#2 Post by Tom »

Hi, Fred.

If it's a 2008R2 server, give the "remote app role" a chance. This allows a streamed application without any problems concerning data management or opportunitistic locking. You file open errors should vanish.

Maybe it's a virus scanner killing your app. Create exceptions for your app and your database folder.
Best regards,
Tom

"Did I offend you?"
"No."
"Okay, give me a second chance."

Cliff Wiernik
Posts: 605
Joined: Thu Jan 28, 2010 9:11 pm
Location: Steven Point, Wisconsin USA
Contact:

Re: File open errors

#3 Post by Cliff Wiernik »

With a new customer, we have an environment where the ADS server is on one W2008R2 server and another W2008R2 server is the Remote Desktop Server (RDP) where all workstations create a remote desktop session to the W2008R2 server. We don't experience any more issues than we would with just a local network environment.

The one thing we see that is needed to avoid fatal errors is to use the newest version of the Xbase++ linker and libraries that disable Microsoft's paging/swapping of the program to disk and/or preferably according Alaska, load the application and dlls on the local workstation drive (or in this case the local drive of the RDP server, so network access is not needed to load the program). That virtually eliminated all fatal errors that were occurring regularly when the RDP computer tried to load the program off the other server that was also hosting the ADS server and the data itself.

Cliff.

Post Reply