Runtime error 5: file access denied

I'm running a program written in TP7.
It's been run in a Pentium III - 450 Mhz
and a fast disk.   The computer runs under Win NT in a local network, but the
program runs in the local drive.
The program does a lot
of read/write operations to binary files.
Sometimes, the program aborts with error 5, sometimes it doesn't.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Have you installed the patch for using
TP7 on computers faster than Pentium 200 MHz ?

If not, here's a link : 


marszeAuthor Commented:
I've installed a patch.  Before that
TP wouldn't run at all.  Are there
different patchs that may affect the
The patch simply fixes the divide by zero error in the Crt unit. It shouldn't have anything to do with acces-denied thingies (Runtime error 5 was "file access denied", wasn't it?).

It could be that the file is write-protected (You can't open a write-protected file with the write attribute, not even with read/write).
This could be caused by:
1) Write protected attribute
2) Other application using the file
3) An other computer accessing the file on your drive, perhaps?
4) Some kind of WinNT stubbornness

Otherwise, I wouldn't know.
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

marszeAuthor Commented:
I turned off the crt unit, just in case...

Runtime error 5 was "file access denied", wasn't it? - that's right

1) Write protected attribute
- none have
2) Other application using the file
- no other applications running
3) An other computer accessing the file on your drive, perhaps?
- no one else in the office (late...)
4) Some kind of WinNT stubbornness
- must be another reason....

Other thing, I've extended the number of maximum open files with a unit called
extend.pas, found in:

Could it be the problem?
marszeAuthor Commented:
Also, the error does not happen
always and also not at the same address.

marszeAuthor Commented:
More information:

the program runs in real mode.
(extend.pas does not work under protected mode).

I'm not sure exactly where the problem lies since I have not seen the code but have you look up error mesaages in pascal??  Those procedures and functions return that type of error
and ONLY they can.  No need for a patch to correct it.  I have made some unnoticed mistakes in some of my code and when I run them some errors like those pop up.  I checked my code and found what I did wrong.  I recomend that you do the same too..

Only human errors can cause those errors..... no offence

we all make mistakes
Access denied error may be caused by one of below reasons:

1. File was opened by another application.
2. File attribute is ReadOnly, System, or Hidden
3. You have no right in this directory, check your login name and rights or that directory.

- If you want only to open file for reading try to assign 0 to FileMode variable if you use typed or untyped files befor using Reset procedure, FileMode = 0 means read only, so that if the file is ReadOnly, System, Hidden, opened by another application for reading, or you have no write access to that file, you can open it and read it using

FileMode:= 0;

Friend Batalf:

   The patch you suggest at that URL simply corrects the executable program you created.

That has the inconvenience of having to run the patcher EACH TIME you compile something. There is a patch a bit smarter than that: it directly corrects the initializing routine at the very CRT unit.

Therefore, you only have replace that patched unit into your TURBO.TPL file so you can forget of patching anything, because now it's simply compile with the patched version, and all run smoothly.

Unfortunately, I've forgot the URL where I've got the patch from, but I can mail my patched version of TURBO.TPL to whoever needs it.
marszeAuthor Commented:
Thank you all for your comments.
The error doesn't seem to be related to a file being used or with a bad attribute.
I reviewed the source(and found some corrections) and suppressed the extend unit (back to the 15 files limit).
The error does not seem to reappear so far.
It could be that this unit make problems in WinNT or that DOS has to be configured in a way that I don't know.
Has anybody tried this unit under WinNT or know of alternative solutions to extend the number of open files?
I'll keep running to see if the error
>>solutions to extend the number of open files?

¿Didn't you think about another way to face your problem?
marszeAuthor Commented:

the program does a complicated process of spliting large matrices into several components.  It reads several input files and produces several new matrices.
The arrays are to large to keep in memory. Some matrices have been added into a single file to reduce the number of files.
The solution could be to run the program in 2 passes, but the time penalty is too high (already the program works several hours).

I've taken the Extened unit out and the error has not appeared so far.  It seems then that this unit had some connection with the problem.  Is a pitty
because it was good to break this limitation.

I haven't been able to find another unit that will allow this and be compatible within WinNT (nor I know enough to find the solution myself)
thanks, if you have other idea let me know.
I think the reason of your problem is--

1. File is opened by yet another program.
2. You may not have right to access the directory contents.
3. Attributes of file are ReadOnly, System, or Hidden.

At last but almost impossible, Any bug in installation of WIN NT.
Isn't this answer exactly what marsze proposed as a comment?
marszeAuthor Commented:
The problem is not file related: the application is run stand-alone, nobody else in the network (or other application) uses the related files.
The files are not read-only and the application is run in the local hardisk with full R/W rights.
A bug in NT or in the installation is something I cannot tell. Other applications run fine.  The problem seem to be related to the unit that extends the number of files, which seem not to work in NT (sometimes does).  As said I took the unit away and the program seem to be running fine so far.  Currently I'm running a simple problem, hopefully it'll continue working in more complicated ones.  It would be nice to find a replacement for the extend unit that works in NT.
As you just said that the program works fine witout the extended unit.  

The problem is in the unit.  You said it so many times.  Now if Borland made a limitation for the number of open files you may have, there must have been a reason.  Now there is a unit that can go past that limitation..
great.. but is this unit COMPLETELY debug????


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.