Access Denied (Dos error 5) with WindowsXP

[qnsoftware]

I have a large database application written in Turbo Pascal 7, accessing a
B-Tree Filer (version 5.54) networked database installed in over forty
sites, all working happily under various Windows systems from 95 to 2000 for
many years. That is until three users (so far) installed new PCs with
Windows XP.

Now I am getting "Dos Error 5" (access denied) messages (with the XP PCs)
when reading a single record control file from the server, using the Dos
routines supplied with B-Tree Filer. As reading this control file is the
first thing the program does, and cannot proceed without it, the program is
inoperable on these XP PCs.

The reading sequence is:-
1. Open file.
2. Lock file.
3. Read record.
4. Unlock file.
5. Close file.

The error occurs on step 3 (read record), which is illogical because it has
just been opened and locked without error.

As a sideline, I had a similar problem on a fast Pentium 4 with WindowsNT
which turned out to be a down level screen driver problem. The screen
drivers have been checked on these latest cases. As all new PCs are super
fast and come installed with XP, it may be a speed problem instead of an XP
problem. I am thinking of the earlier Turbo Pascal word overflow problem,
could we something similar here?

As the problem is a solid one there must be a simple solution, but it has
eluded me so far. Can anyone help please?

Bill Keown (Qn Software Services)

[O.Chaillot]

NetBIOS is not automatically activated with XP. Did you check it ?

"qnsoftware" <qnsof...@computerweekly.net> a écrit dans le message de
news: 2qNb421U...@tpsmail01.turbopower.net...

[qnsoftware]

I have some updated information to the "Dos error 5" problem.

Previously I was getting the problem only on fast Pentium 4 machines running
Windows XP. I have now had reported to me that a Pentium 3 (800Mhz) running
Windows 2000 is showing the same problem when attaching it to the network.

I am beginning to think it may be something to do with the registry settings
but I have no idea what.

HELP!

[Rob Roberts [TPX]]

Bill,

> The reading sequence is:-
> 1. Open file.
> 2. Lock file.
> 3. Read record.
> 4. Unlock file.
> 5. Close file.

Just a thought; perhaps you could try changing your reading sequence to
this:

1. Open file (in exclusive, non-sharable mode, and with retry logic in case
another workstation is accessing it at the same time).
2. Read record. (No lock is needed since the file is open in non-sharable
mode.)
3. Close file.

--Rob [TPX]

[Rob Roberts [TPX]]

Bill,

I'm not ignoring your question, it's just that I have no idea whatsoever
what the problem is or how to solve it. Did you see O.Chaillot's reply?
(It might not apply, since you mentioned that the problem is now happening
on Win2K, too.)

--Rob [TPX]

[qnsoftware]

O. Chaillot,

Many thanks for the NetBIOS suggestion. I will check it out.

There will be a delay before I can do so as there is a 7 hour time
difference (I am in the U.K.) and the nearest site with the problem is over
100 miles away.

I will let you know.

Bill

[qnsoftware]

Rob,

Thanks for your reply. The file I am trying to access is not a Btree Filer
Fileblock. It is a simple single record Dos file where record 0 (1024 bytes)
is the record I am trying to read. So I don't think your suggestion would
apply here.

To be more specific, essentially the reading sequence is:-
1. Assign(F,'R:\REG3\NCTL.DTA').
2. Reset(F,1024).
3. DosLockRec(F,0,4).
4. Seek(F,0).
5. BlockRead(F,D,1).
6. UnLockDosRec(F,0,4).
7. Close(F).

Each step is error checked and retried if necessary. The locking is done
with the functions supplied in the SHARE unit. The error is on step 5.
BlockRead.

Perhaps there is a better way of handling such files over a network. Any
suggestions?

Bill.

[Rob Roberts [TPX]]

Bill,

> Thanks for your reply. The file I am trying to access is not a Btree Filer
> Fileblock. It is a simple single record Dos file where record 0 (1024
bytes)
> is the record I am trying to read. So I don't think your suggestion would
> apply here.

No, it still applies. You can use the Windows CreateFile function to open
the file in non-sharable mode. (In spite of the rather misleading name,
CreateFile can be used to open already-existing files.)

> To be more specific, essentially the reading sequence is:-
> 1. Assign(F,'R:\REG3\NCTL.DTA').
> 2. Reset(F,1024).
> 3. DosLockRec(F,0,4).
> 4. Seek(F,0).
> 5. BlockRead(F,D,1).
> 6. UnLockDosRec(F,0,4).
> 7. Close(F).

This is completely off the top of my head and untested, but your reading
sequence would look something like this:

var
FHandle : THandle;

FHandle := CreateFile(PChar(R:\REG3\NCTL.DTA), GENERIC_READ or
GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if FHandle = INVALID_HANDLE_VALUE then
{Appropriate error handling... }
else
try
if not ReadFile(FHandle, D, 1024, BytesRead, nil) then
{Appropriate error handling... }
finally
CloseHandle(FHandle);
end;

Note that seeking to location 0 isn't necessary, because the file pointer is
set to location 0 when the file is first opened. Locking also isn't
necessary, because you have exclusive, non-sharable access to the file. But
you will need to include retry logic, in case another workstation has the
file open at the same time.

--Rob [TPX]

[qnsoftware]

Update to Dos Error 5 problem.

The NetBios setting has been checked ok on all machines. But an interesting
fact has emerged. One user has installed two identical XP machines with the
same service packs applied and same hardware configuration. One works fine,
but the other has the solid Dos Error 5 problem. The XP settings seem to be
identical (including the CONFIG.NT) , but obviously there must be a
difference - but where? Any XP experts out there?

As a side issue, I used the "NetBiosInstalled" function in the NETBIOS
routines supplied with BTree Filer but it always returns false on all
machines, even those working correctly. Is this correct?

Bill

[Rob Roberts [TPX]]

Bill,

> As a side issue, I used the "NetBiosInstalled" function in the NETBIOS
> routines supplied with BTree Filer but it always returns false on all
> machines, even those working correctly. Is this correct?

Sorry, but I have no idea whether that should work right on XP. Those
routines were written back in the DOS days, and in fact can't even be
compiled under Delphi 32-bit. So it wouldn't surprose me if they didn't
work right under XP, but I really don't know.

--Rob [TPX]

[qnsoftware]

The problem proved to be a bug in Novell Client 4.83.

I was proved by down grading to version 4.80. But I have since learned that
applying Service Pack 1 is the correct fix.

Thank you to everyone for for your time and efforts they were all very much
appreciated.

Bill Keown