DOS Error 33 - any advice?

[George T]

I am getting intermittent error:

Error DBFCDX/1011 Write error:
dbfile.dbf
(DOS Error 33) -> this is 'Lock violation'

It happens on a DBAPPEND() line - called from DBAPPEND(0)

Same exact code had no such issue in Clipper 5.2e before conversion to xHarbour.

Please advise how to address this or is there a way to Catch..Try? - please suggest how to do that. The occurrence of this error in a large dbf file may lead to serious damage to the data at any time now.

Thanks,
George

[dlzc]

Dear George T:

On Wednesday, December 17, 2014 9:40:06 AM UTC-7, George T wrote:
> I am getting intermittent error:
>
> Error DBFCDX/1011 Write error:
> dbfile.dbf
> (DOS Error 33) -> this is 'Lock violation'
>
> It happens on a DBAPPEND() line - called from
> DBAPPEND(0)

How many places do you use this in your code? Did you wrap it in a UDF, so that you can do the "fun stuff" just one place?

> Same exact code had no such issue in Clipper
> 5.2e before conversion to xHarbour.

Clipper runs in COMMAND.COM, so it had an NTVDM session (where it runs at all). (x)Harbour runs in CMD.EXE, so does not have the same "protections" or lies to the code.

> Please advise how to address this or is there
> a way to Catch..Try? - please suggest how to
> do that.

Wrap the call in a UDF.
TRY ... CATCH
... repeat each 1/2 second until it does not throw an exception, for 3 seconds max. Then where you put the UDF, you need to handle failing to add a blank record.

> The occurrence of this error in a large dbf
> file may lead to serious damage to the data at
> any time now.

Yes, and the tweaks we put in the registry to speed things up, make that even easier to happen.
https://groups.google.com/d/msg/comp.lang.xharbour/h42PFe8H_wQ/9o7SE81JRjQJ

David A. Smith

[danca]

George, try to be more precise, f.e. specify if you are in a networked
environment, and which kind of file server are you using if this is the
case.
In a single-user scenario this error is very unlikely, and you could
check the hard disk for failures.
A code fragment would be useful.
Dan

[George T]

Dan,
I agree with you that this will never happen in a single-user scenario.

This happens in a multi-user network environment and the error is from a batch job running directly on the server itself (2003 server). The XP clients connecting to the server do not get the error.

I will need an example how to catch and process the error.
Here is my current code:

success = .F.
DO WHILE (.NOT. success)
DBAPPEND() <-- thisi is where the error occurs
success = .NOT. NETERR()
IF (.NOT. success)
INKEY(0.5)
ENDIF
ENDDO

Please suggest how this simple piece of code should be changed in order to handle the DOS Error 33.

I do not understand what is wrong with the above code - it worked in Clipper, and it should be working in xHarbour without any changes. And why NetError does not catch and handle this error?

Thanks in advance,
George

[dlzc]

Dear George T:

On Wednesday, December 17, 2014 1:13:43 PM UTC-7, George T wrote:
...

> Here is my current code:
>
> success = .F.
> DO WHILE (.NOT. success)
> DBAPPEND() <-- thisi is where the error occurs
> success = .NOT. NETERR()
> IF (.NOT. success)
> INKEY(0.5)
> ENDIF
> ENDDO
>
> Please suggest how this simple piece of code should
> be changed in order to handle the DOS Error 33.

It should not be changed based on the docs. The example for Clipper 5.3 and xHarbour is exactly the same, with NetErr() (as a logical) used to judge whether or not the DbAppend() call was successful.

> I do not understand what is wrong with the above
> code - it worked in Clipper, and it should be
> working in xHarbour without any changes. And why
> NetError does not catch and handle this error?

I concur.

By the way, NetAppend() appears to be superior, and will let you get rid of the loop. It will try for so many seconds, then abort. You just need to prepare to handle a return value that it simply *cannot* get a record added.

Can you tell us which xHarbour version you are running, OS and such?

Please note that:
NetErr() returns a logical, and
NetError() (you typed NetError above) is a different function and may not have the correct value unless you use a NetAppend() call or similar. Make sure you do not have a typo.

David A. Smith

[George T]

On Wednesday, December 17, 2014 11:40:06 AM UTC-5, George T wrote:

David,
Sorry, NetError above was a typo - I am using NETERR() - with the latest xHarbour.com released 1 week ago.

I looked to replace my code above with NetAppend() but decided against it(without testing), only because the docs say "...and prompts the user if the operation should be retried or aborted".
If the docs are correct (do you know?), for this job, there is noone sitting in front of the server to respond to that prompt what should be done when this happens.

George

[danca]

dbappend() in my experience only gives error if the file is locked by
another process (with flock()).

Try... catch or the "classic" costruct begin sequence... break (oErr)...
recover with oErr... end sequence give you the full control of the error
condition (the only errors that are not catched are GPF's or worst).

Neterror() is not per se a show-stopper, it simply returns false, while
error 33 is.

So you get the error before neterr() is evalued, because the operation
that fails is dbappend(), and you need to control the error via try...
catch or begin sequence... etc.

Dbappend() appends a record and locks it. Thus, the lock only occurs if
the program has been able to append a new record. And he can't append a
record if the file is locked, or otherwise unavailable. But here we can
exclude network errors, we are on the server. So why the file could be
unavailable? Permissions are to exclude if the error is intermittent,
isn't it? File lock seems to be the obvious answer.

And change inkey(.5) with hb_idlesleep(.5)

Let us know.
Dan

[dlzc]

Dear George T:

On Wednesday, December 17, 2014 2:06:18 PM UTC-7, George T wrote:
...

> Sorry, NetError above was a typo - I am using NETERR()
> - with the latest xHarbour.com released 1 week ago.

Please verify that is what it is in your code, too.

> I looked to replace my code above with NetAppend()
> but decided against it(without testing), only
> because the docs say "...and prompts the user if
> the operation should be retried or aborted".
> If the docs are correct (do you know?),

Assume it does.

> for this job, there is noone sitting in front of
> the server to respond to that prompt what should
> be done when this happens.

Until this is acknowledged as a bug and repaired, you could

success = .F.
DO WHILE (.NOT. success)

doserror( 0 )

DBAPPEND() <-- thisi is where the error occurs

success := (doserror() == 0)

IF (.NOT. success)
INKEY(0.5)
ENDIF
ENDDO

David A. Smith