dcabe not freeing file locks on Windows 2003 (5.0.14 native)

[Nancy Palmquist]

Fairlight wrote:
> I had occasion to modify about 90% of my tables when adding a new feature
> (well, improving on something, actually, which would negate the need to
> modify this ever again).
> 
> I've noticed that on Windows 2003 Server, when I used *cabe, if I exit a
> table (get out of edit mode from the PRC, either by save or by break),
> sitting at the 4-option menu (auto, input, output, change file) still has
> the file locked, as WinZip gripes about the file being locked when I go to
> archive.  Technically, it should be unlocked at that point, as the file
> should be closed since I'm no longer editing it.
> 
> The problem is wider ranging and cumulative.  5.0.14 on Win2K3 Server.
> 
> After editing the files below, each in turn, all within the same dcabe
> session, I went to edit another and hit the following glorious display
> (reformatted to look sane in email):
> 
> 
> *** A System Error Has Occurred ***
> /filepro/cgi_control/auto.prc: Too many open files
> 
> 
> Open files:  
> 1 : /filepro/cgi_control/disp_menu1.prc, 
> 2 : /filepro/cgi_control/edit_tax.prc, 
> 3 : /filepro/cgi_control/errpage.prc,
> 4 : /filepro/cgi_control/excise_form.prc, 
> 5 : /filepro/cgi_control/excise_total1.prc, 
> 6 : /filepro/cgi_control/login.prc,
> 7 : /filepro/cgi_control/excise_total1.prc, 
> 8 : /filepro/cgi_control/insert_session.prc, 
> 9 : /filepro/cgi_control/name_search_form.prc,
> 10 : /filepro/ cgi_control/o_city_display.prc,
> 11 : /filepro/cgi_control/o_disp_city_login.prc,
> 12 : /filepro/cgi_control/o_disp_menu1_err.prc,
> 13 : /filepro/cgi_control/print_bill.prc, 
> 14 : /filepro/cgi_control/return_posted_tax.prc, 
> 15 : /filepro/cgi_control/search_name1.prc, 
> 16 : /filepro/cgi_control/select_action1.prc, 
> 17 : /filepro/cgi_control/tax_by_name.prc
> 
> 
>  Press  H -Hardcopy  ?--+ -Continue
> 
> 
> Needless to say, I'm annoyed.  Those should be closed whenever I exit the
> table proper.  I won't get into the shortage of three fd's that technically
> aren't supposed to be used under Windows, thus triggering it three fd's
> early.  The fact that it happens at all is indicative of a problem.
> 
> I was the only person editing the files.  Further, that list is in
> -exactly- the order in which I edited them.
> 
> mark->
Mark,

Just noticed your post.  Sorry but I am changing over my windows 
computer and installing software has taken up my time the last few days.

I have seen the same locking.  It seems you have to exit *cabe all the 
way to release the lock on the processing on some windows platforms. 
This is not the same on *NIX stuff, but on windows I get it all the time.

The lock does not seem to be released until *cabe is closed.  Now I must 
say that I have done a lot of programming but I have never had it issue 
the two many open files message.  Maybe going in and out of the same 
process table does not generate another lock, just reuses.

I have seen the same behavior in other places.  In *clerk, when you save 
a record, it seems the lock will often persist until you lock another 
record.

Nancy

-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com