DOS ERROR 5 - How to fix

[wildcard]

Client was using PKZIP across a network
connection when someone else opened a file
currently being zipped... the workstation hung
and the only way out of it was to reboot that
workstation.

Now that particular workstation can no longer
use our program because a required datafile
gives an error message - DOS ERROR 5. We have
done a complete shutdown of the workstation
and restarted WIN98 but no joy.

Other workstations can access the program and
that datafile OK. How do we remedy this problem
for this particular workstation?

Thanx in anticipation,
Jim

 

[EzLogic]

What is exactly the error:
DBFNTX/1010?
1020?
1005?

Do you have NG? norton guide? What clipper version do you have? AK

 

[EzLogic]

By the way: Dos error 5 is "Access is denied"
so, check what rights does this station have? Check for network validation, etc...

AK

 

[wildcard]

Hi TeknoSDS

Actual error message reads:-

DBFNTX/1001 open error CONTROL.DBF
DOS ERROR 5

I am aware (of course) that DOS error 5 means
access denied. Yes I have Norton Guides. Yes
I have full CLIPPER documentation. Bit useless when
there is no explanation anywhere about DOS errors !!

Clipper Version is 5.2B
Application was compiled with RTLINK.

The workstation has WRITE access to the hard drive
on the WIN2K server where the system resides.
All other workstations can open and write to this
critical CONTROL.DBF quite happily.

Jim

 

[EzLogic]

are you using PPP library by chance? Protection Plus Professional?

Ok, here's the scenario. ON Win2k server. There is an option where you can see open shares or open files (I don't know exactly the name) but, I know it is under the control panel->Administrator tools (or something like that)...

I have experienced that sometimes Win2k server keeps open ntx and dbf files for stations. And they don't flush. After even after I reboot the station. So, I manually release open shares.

They might be causing the problem
let me know what happens. Good luck!
AK

 

[wildcard]

Released the database at the server and all is well

thanx.
Jim

 

[Michael42]

I have noticed on NT running chkdsk (which requires a reboot) has fixed this problem. Perhaps some bad ACL info was written in these instances.

In 5 years I only had to do this 3 times (for 50+ NT servers) - but it stilled fixed it when it occured.

Michael