DBFNTX 1020 and 1003 errors

[hardyone]

thread288-1600081

I'm back with index opening issues similar to my previous dbf opening issues. Using a net_use function like the one Jock showed me last time gets my dbf's open reliably now. Thanks for that help. But I've had increasing problems recently with crashes related to index files not opening. Tracking my error messages I find DBFNTX 1003 index open error in respone to a "set index to <ntx>" command, followed by DBFNTX 1020 workarea not indexed error in response to the following "Seek..." command.
So does Jock or anyone else have a function they use to test for successful opening of index files? Or is there another way to fix this? Thanks.

 

[GriffMG]

Have you looked at your file handles?

In modern Windows environments we don't have to worry too much about how many files handles are open, but dear old Clipper is obsessed with it.

Unfortunately, how you set them is a bit OS verseion dependant.

Which OS are you running on?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[hardyone]

The referenced previous thread discussed the possibility that this was a file handle issue but that is DOS error 4. I am gettng DOS error 32: sharing violation.

FYI I am using XP SP3. The problem is happening with two different programs running on two diffrent machines so it is not an isolated issue.

I did some research to see if I could create a fix for this on my own. Thought of using neterror() like before but that apparently only works after USE or APPEND BLANK, not SET INDEX TO <ntx>. I might be able to test with indexkey() which returns null if no index exits..... I'm a novice: I'll see if you experts have already developed a fix.

 

[GriffMG]

That's a bit more interesting, are the files being opened on a Windows Server?

If so, check out opportunistic file locking...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[DTracy]

Also, check the permissions on the folder where the files are located. Set user to "everyone" with full read/write permissions for a test.

David.

 

[JockMullin]

Sorry I didn't see this sooner - don't often check this forum any more as there is so little traffic nowadays.

These ongoing problems are quite mysterious. I have never seen a sharing violation opening an index unless another task is accessing the file. As before, I am thinking an external program (antivirus, backup or malware) is blocking access.

If it were a rights issue I would expect DOS error 5 (access denied) but you are getting 32 (sharing violation), which means either the file is opened exclusively by another task or is read-only.

Does this happen in safe mode with networking?

How about doing something like:
set exclusive on
delete file indxname.ntx
use dbfile
index on keyfields to indxname
set index to indxname

Do you get the error then, after having just created the index from scratch?

Is this happening with all index files, or just one in particular. If one, what are the keyfields; does it contain any function references?

What version of Clipper?

Don't have anything more cogent to offer at this point, sorry.


Jock

 

[JockMullin]

Hi again

This was bugging me, so I set up to do some testing and found a scenario which gave me the same error you are experiencing.

Normally I write my programs to open all files and indexes as early as possible - a holdover from the days of file handle problems.

This time what I did was create a little program which opened 6 dbf's and associated ntx's (8 in all), and loop around doing some I/O, then closing and reopening them separately. Sure enough, once or twice I got sharing violations opening an index file I had just closed when I tried to reopen it.

Then I went and disable windows write caching on the disk, and the problem went away. So in fact what was happening is that Windows itself was still writing cached data to the file after I closed it at the point I tried to reopen.

So, there would be two possible solutions:
- open your files and indexes at the outset and don't close them until finished for good, or disable write caching on the drive. Instructions for doing that can be found here:

http://www.windowsnetworking.com/kb...AdminTips/Miscellaneous/DiskWriteCaching.html

Note that doing so will slow down overall system performance, but will enhance data integrity.

Hope this helps
Jock

 

[hardyone]

Thanks for your reponses. I'll reply to each of you:

Griff: each program runs on its own local harddrive. Folders can be shared but the errors do not involve sharing within Clipper programs. By “opportunistic file locking” are you referring to Clipper’s Flock() or something in Windows?

David: Where are the permissions? I looked in Windows and couldn’t find what you were referring to.

Jock: 1) I’m using Clipper 5.2 with the 5.2d patch. 2) The problem occurs with multiple different NTX files, and typically in routines that are used frequently (like repainting the screen with data). I assume that is because those files are opened more frequently so more likely to run into trouble--though at first it did make me wonder if it was problem with those particular parts of the program (this dates back to the earlier dbf opening failures which were fixed with the net_use function you posted). 3) Seems like recreating the index each time might slow things down, but I suppose not in current environments. However I still have to Set Index to Indxname so I’d run into the same trouble there. 4) Disabling write caching might be something to consider as another reason for the sharing violation but.....

But here’s my conclusion: it is my Computer Associates antivirus program. (How’s that for irony?) By disabling real time protection on the machine that was crashing three times a day there have been no crashes the last two days. Pretty good circumstantial evidence I think.
In the last few days I’ve written this routine to use instead of “Set Index To…” Watching with my error trapping routine I think I saw an instance when it worked successfully allowing the index file to open on the second try. Obviously I don’t want to run the computers without real time virus surveillance so I’m still working on replacing all my "Set Index To’s" with Set_ntx({“indxnam1”,”indxnam2”})

PROCEDURE SET_NTX()
/*opens ntx files checking success.
parameters: array of ntx files to open (names in quotes)
numeric wait time in seconds or empty for default of 30 seconds */

PARAMETERS FILES, WAIT
//set variables
PRIVATE ASAVE, N, WSAVE
PRIVATE NUMB := LEN(FILES)
PRIVATE NNTX := 0 //number of index files successfully opened.
IF EMPTY(WAIT)
WAIT = 30 //default is 30
ENDIF
WSAVE = WAIT

//loop to open ntx's
FOR N = 1 TO NUMB
//open each ntx
WAIT = WSAVE //reset wait
DO WHILE WAIT > 0
DBSETINDEX(FILES[N])
//test for open
IF LEN(INDEXKEY(NNTX+1)) > 0
/* if argument equals zero intially it checks controlling index
so the test fouls if second index not opened since controlling index still there */ /*in looking at this again I guess I could just initialize with NNTX :=1 and use argument of NNTX and it would work as well*/
NNTX++
EXIT
ENDIF
//watch the time
INKEY(1) //wait 1 second
WAIT = WAIT - 1
@ 0,72 SAY 'NTX ' + ALLTRIM(STR(WAIT))
ENDDO
//handle unsuccesful opening
IF WAIT = 0
ASAVE = SAVESCREEN(10,15,20,63)
@ 10,15 CLEAR TO 20,63
@ 10,15 TO 20,63
@ 12,17 SAY FILES[N] + ' NOT OPENING'
@ 14,17 SAY 'Alt-C NOW TO ABORT'
@ 16,17 SAY 'OR "Y" TO CONTINUE PROGRAM WITH UNOPENED INDEX'
@ 18,17 SAY ' CAUSING MALFUNCTION OR CRASH'
DO WHILE .NOT. UPPER(CHR(INKEY())) $ 'Y'
ENDDO
RESTSCREEN(10,15,20,63,ASAVE)
ENDIF
NEXT
RETURN



I'm glad for any other feedback/answers. Thanks.

 

[DTracy]

Glad to hear you found the problem.

The permissions are located in the security tab of each folder.

Right click on the desired folder, select the Security tab, and then permissions. If you don't have the authority to change permissions, you will not have access. This presumes you are an administrator.

David.

 

[GriffMG]

Opportunistic file locking only relates to tables placed on a file server and shared.

A long, long time ago M$ was trying to prove that it's networking was better than Novell Netware, and they started doing this op' locking to make some of the more innocent journos of the day think it was blindingly fast.

They made it so that if you opened a small file and asked for it to be shared - they actually opened it exclusively and sent a copy to the workstation (effectively). This meant that instead of dragging data across the Local Area Network, they worked locally without telling anyone. Of course if user No. 2 tries to open the file, he can't and it all grinds to a halt. I don't know why they keep it - and in Win 7/Server 2008 it's a pain to remove, you have to get rid of SMB2.

That's my version - it may no be 100% right, but it is the gist.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.