(DOS Error 32) DBFCDX/1006 ¿bug?

[John Salazar]

Hello:

I use Harbour 3.1 and Windows 7 64 bits.

When I run this code, very often I got:
(DOS Error 32) DBFCDX/1006 Create error: C:\Users\John\Desktop\harbour
\DATA\CUSTOMER.cdx


Working sample at:
http://www.mediafire.com/?47nd41ki6l87jgx

Please, unzip and create a folder at your Desktop.


This is the code:

#define CRLF Chr(13)+Chr(10)

STATIC pPath

//--------------------------------------------------------------
FUNCTION MAIN()
//--------------------------------------------------------------


LOCAL i := 0

pPath := hb_dirbase()+"DATA"




REQUEST DBFCDX, DBFFPT
RDDSETDEFAULT( "DBFCDX")


SET EPOCH TO 1990
SET CENTURY ON
SET DATE ITALIAN
SET DELETED ON
SetCancel( .F. )
SetHandleCount( 150 )




SELECT 1
USE (pPath+"\CUSTOMER") NEW



for i:= 1 to 100
reindex()
next

alert(str(i)+CRLF+CRLF+PPATH)
dbcloseall()
quit

RETURN NIL
//--------------------------------------------------------------



//--------------------------------------------------------------
FUNCTION REINDEX()
//--------------------------------------------------------------


SELECT ("CUSTOMER")
FERASE (pPath+"\CUSTOMER.CDX")
PACK

INDEX ON FIELD->LAST TO (pPath+"\CUSTOMER")
dbCommit()


return nil
//--------------------------------------------------------------



What´s wrong?.

Thank you very much.

[bart...@interia.pl]

Hello John,

Saturday, February 11, 2012, 9:54:00 PM, you wrote:

JS> Hello:

JS> I use Harbour 3.1 and Windows 7 64 bits.

JS> When I run this code, very often I got:
JS> (DOS Error 32) DBFCDX/1006 Create error: C:\Users\John\Desktop\harbour
JS> \DATA\CUSTOMER.cdx

JS> Working sample at:
JS> http://www.mediafire.com/?47nd41ki6l87jgx

JS> Please, unzip and create a folder at your Desktop.

JS> This is the code:

JS> #define CRLF Chr(13)+Chr(10)

JS> STATIC pPath

JS> //--------------------------------------------------------------
JS> FUNCTION MAIN()
JS> //--------------------------------------------------------------

JS> LOCAL i := 0

JS> pPath := hb_dirbase()+"DATA"

JS> REQUEST DBFCDX, DBFFPT
JS> RDDSETDEFAULT( "DBFCDX")

JS> SET EPOCH TO 1990
JS> SET CENTURY ON
JS> SET DATE ITALIAN
JS> SET DELETED ON
JS> SetCancel( .F. )
JS> SetHandleCount( 150 )

JS> SELECT 1
JS> USE (pPath+"\CUSTOMER") NEW

JS> for i:= 1 to 100
JS> reindex()
JS> next

JS> alert(str(i)+CRLF+CRLF+PPATH)
JS> dbcloseall()
JS> quit

JS> RETURN NIL
JS> //--------------------------------------------------------------

JS> //--------------------------------------------------------------
JS> FUNCTION REINDEX()
JS> //--------------------------------------------------------------

JS> SELECT ("CUSTOMER")
JS> FERASE (pPath+"\CUSTOMER.CDX")
JS> PACK

JS> INDEX ON FIELD->LAST TO (pPath+"\CUSTOMER")
JS> dbCommit()

JS> return nil
JS> //--------------------------------------------------------------

JS> What�s wrong?.

JS> Thank you very much.

You have error beacuse try erase opened file customer.cdx - if you
only reindex - works fine :)

Best regards,
bartsoft mailto:bart...@interia.pl

[John Salazar]

Hello,

Thanks for reply.

I do not open customer.cdx

Just:

USE (pPath+"\CUSTOMER") NEW

And the error does not occur always.

So I am afraid it is not the point.

Thanks anyway.

> JS> What�s wrong?.

>
> JS> Thank you very much.
>
> You have error beacuse try erase opened file customer.cdx - if you
> only reindex - works fine :)
>
> Best regards,

>  bartsoft                            mailto:barts...@interia.pl

[Massimo Belgrano]

Problem seem be in CUSTOMER.dbf
Try create a new dbf using dbcreate
remember structural .cdx files open automatically file with same name when the associated table is opened, 

> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users




--
Massimo Belgrano

[Massimo Belgrano]

   You must do ferase only if cdx is not opened

   sele customer

   use

   FERASE  (pPath+"\CUSTOMER.CDX")

 

 

        PACK

        INDEX ON FIELD->LAST TO (pPath+"\CUSTOMER")

--
Massimo Belgrano

[Alex Strickland]

Hi John

> I use Harbour 3.1 and Windows 7 64 bits.
>
> When I run this code, very often I got:
> (DOS Error 32) DBFCDX/1006 Create error: C:\Users\John\Desktop\harbour
> \DATA\CUSTOMER.cdx

I get intermittent and inexplicable errors of a similar sort on Win7.

Look at this crap code:

DBUSEAREA(lNewArea, cDriver, cName, xcAlias, lShared, lReadonly)

IF NETERR()
DebugOut("NETERR() is true on " + cName)
// Voodoo
Sleep(1000)
DBUSEAREA(lNewArea, cDriver, cName, xcAlias, lShared, lReadonly)
IF NETERR()
DebugOut("NETERR() is true on " + cName + ", Win 7?")
RETURN
ENDIF
ENDIF

I find the sleep "fixes" it, voodoo indeed.

I should be interested to find out if it helps you at all. The exact
same executables never exhibit this behaviour on any other Windows version.

--
Regards
Alex

[John Salazar]

Hi Alex,

Thanks for helping me.

I modified the sample to use the dbf in exclusive mode and rename to
cust.dbf, so the index is not opened.

Sample updated:
http://oron.com/8otfjgsek4zq

I get the same error very often.

So it is a bug.

Hope the team reviews it.

Thanks again.

[Klas Engwall]

Hi Alex,

>> I use Harbour 3.1 and Windows 7 64 bits.
>>
>> When I run this code, very often I got:
>> (DOS Error 32) DBFCDX/1006 Create error: C:\Users\John\Desktop\harbour
>> \DATA\CUSTOMER.cdx
>
> I get intermittent and inexplicable errors of a similar sort on Win7.

You did not say what "similar sort" means :-). It would be interesting
to know the DOS error number.

> Look at this crap code:
>
> DBUSEAREA(lNewArea, cDriver, cName, xcAlias, lShared, lReadonly)
>
> IF NETERR()
> DebugOut("NETERR() is true on " + cName)
> // Voodoo
> Sleep(1000)
> DBUSEAREA(lNewArea, cDriver, cName, xcAlias, lShared, lReadonly)
> IF NETERR()
> DebugOut("NETERR() is true on " + cName + ", Win 7?")
> RETURN
> ENDIF
> ENDIF
>
> I find the sleep "fixes" it, voodoo indeed.
>
> I should be interested to find out if it helps you at all. The exact
> same executables never exhibit this behaviour on any other Windows version.

In John's case, Massimo is clearly on the right track. So a
set(_SET_AUTOPEN,.F.) at the top of the code should be the solution. Or
a dbclearindex() before the ferase(). Except that the OS might keep the
file open from a previous use and thus prevent ferase()ing it,
especially if it was previously used exclusive.

Regarding your intermittent errors, have you applied the "usual"
registry fixes as described for example on Nick Ramsay's NT networking
page? Here:

http://www.witzendcs.co.uk/html/nt_networking.html

Those settings were collected in the comp.lang.clipper newsgroup over a
period of several years and apply to file sharing in general, not just
file sharing in the NTVDM. Google the registry key names found in the
.reg files at Nick's page to get more info.

Since we do not know if the registry settings have been fixed on every
workstation running our applications it is probably a good idea to take
som precautions. Your voodoo trick works well, in my experience, when
closing a file and then ferase()ing it. It gives the OS a little moment
to settle.

Regards,
Klas

[Alex Strickland]

Hi John

> Thanks for helping me.
>
> I modified the sample to use the dbf in exclusive mode and rename to
> cust.dbf, so the index is not opened.

I'm not sure I understand you here.

> Sample updated:
> http://oron.com/8otfjgsek4zq
>
> I get the same error very often.

Yes, I ran your app 7 times and then got the error.

> So it is a bug.

Yes, but in Win 7 I think. By the way my OS is also Win7 64bit.

> Hope the team reviews it.

Well, in view of the fact that it seems to be OS related, I doubt it.
Strange though, that it is always to do with indexing, so maybe.

--
Regards
Alex

[Alex Strickland]

Hi Klas

> You did not say what "similar sort" means :-). It would be interesting
> to know the DOS error number.

I'm afraid I didn't write it down. I think it was the same error.

> In John's case, Massimo is clearly on the right track. So a
> set(_SET_AUTOPEN,.F.) at the top of the code should be the solution. Or
> a dbclearindex() before the ferase(). Except that the OS might keep the
> file open from a previous use and thus prevent ferase()ing it,
> especially if it was previously used exclusive.

I am sure it is something to do with win7 and/or 64 bit. A retry was
always OK. And my app runs on many other machines (of course my fix may
be hiding the issue, in which case you may be right).

> Regarding your intermittent errors, have you applied the "usual"
> registry fixes as described for example on Nick Ramsay's NT networking
> page? Here:
>
> http://www.witzendcs.co.uk/html/nt_networking.html
>
> Those settings were collected in the comp.lang.clipper newsgroup over a
> period of several years and apply to file sharing in general, not just
> file sharing in the NTVDM. Google the registry key names found in the
> .reg files at Nick's page to get more info.

I do generally use OS_NetRegOK() to do this but I have not on this
machine (my own). But, I've always thought that the registry entries
apply only for networking? The errors occur on a standalone machine.

> Since we do not know if the registry settings have been fixed on every
> workstation running our applications it is probably a good idea to take
> som precautions. Your voodoo trick works well, in my experience, when
> closing a file and then ferase()ing it. It gives the OS a little moment
> to settle.

I hate that sort of thing, that's why I call it voodoo.

--
Regards
Alex

[Klas Engwall]

Hi Alex,

>> You did not say what "similar sort" means :-). It would be interesting
>> to know the DOS error number.
>
> I'm afraid I didn't write it down. I think it was the same error.

OK. If you get a DOS error 32 it is definitely generated by the OS.
Something that happens out of the application's control. So we have to
reconfigure the OS or code around it wherever it is likely to happen.

>> In John's case, Massimo is clearly on the right track. So a
>> set(_SET_AUTOPEN,.F.) at the top of the code should be the solution. Or
>> a dbclearindex() before the ferase(). Except that the OS might keep the
>> file open from a previous use and thus prevent ferase()ing it,
>> especially if it was previously used exclusive.
>
> I am sure it is something to do with win7 and/or 64 bit. A retry was
> always OK. And my app runs on many other machines (of course my fix may
> be hiding the issue, in which case you may be right).

If the issue is of a temporary nature and your retry fix takes care of
it, whether we call ut "hiding" or not, then everything is OK, IMO. In
Clipper I always used the Net_Use() function from the S87 samples,
heavily modified through the years. In xhb and Harbour I gave it a total
makeover to fully support all dbusearea() arguments. In general, it
retries a number of times for 5 or 10 seconds. After that time the user
can select to retry again, as long as he/she cares, or to quit if the
error cannot be solved by waiting. I am sure it hides many temporary
problems, network glitches or whatever, which is exactly what I wanted.
And it hardly ever gets to the point where the user gets involved.

> I do generally use OS_NetRegOK() to do this but I have not on this
> machine (my own). But, I've always thought that the registry entries
> apply only for networking? The errors occur on a standalone machine.

There may be additional issues with Win7/32 and even more of them with
Win7/64 that are not addressed by the old registry fix documentation and
that I am not aware of. But my old Clipper apps are still very much
alive, so my users have not switched to Win7 yet.

>> Since we do not know if the registry settings have been fixed on every
>> workstation running our applications it is probably a good idea to take
>> som precautions. Your voodoo trick works well, in my experience, when
>> closing a file and then ferase()ing it. It gives the OS a little moment
>> to settle.
>
> I hate that sort of thing, that's why I call it voodoo.

But in a way it makes sense, especially if you know that the OS keeps
files open in the background, even if you close them, to help you open
them quicker the next time you need them. And even if you turn off
caching it still makes sense that it will take a short moment to get the
file properly closed. It is a question of timing between the OS and our
apps. So it is a good idea to give it time to do what it must do. A
whole second may be overkill, but most of the time waiting that second
is not a problem from the user's point of view.

Regards,
Klas

[Heinz V Bergen]

Regarding caching and oplocks and now SMB2 in Server2008, Win7 see
also link:

http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html

Regards,
Heinz

> Klas- Hide quoted text -
>
> - Show quoted text -

[Rafa Pabd]

In multitag index creation, after 1st ordCreate() to do OrdListClear()