Record locking

[Bill Akers]

GCC Consulting wrote:
> We all know that after doing a protected lookup using write filename should
> unlock the record to which the lookup was done.
> 
> System:
> filePro native 5.0.11
> Server Dell with 1GB RAM, mirrored 18K RPM drives, Windows server 2003, network
> 3com Hub 100Mbs.
> Workstations: various make clones all running Windows XP pro 900+ GHz to 2+ GHZ.
> 
> No internet connections - no service paks or updates applied.
> 
> I recently completed an upgrade of their order entry system including a
> procedure for getting the next available order number from a master file.  A
> procedure most of us use.
> 
> Problem arose in that the master file record was not being unlocked quickly
> enough causing no number to be retrieved or getting an error message that the
> record was locked by another process.
> 
> @wlf1 if: 1 = ""
>     then: GOTO get_num
>       if:
>     then: "other code"
>  ..........
> 10 Get_num if:
>       then: rn(8,.0)="1"
> 11	  if:
>        then: lookup emm = em_mast  r=rn    -np
> 12	  if:	 not emm
>        then: ERRORBOX "Master File Not Found";EXIT
> 13	  if:
> 	 then: po_num=emm(10);GOSUB chk_num			(chk_num does a
> lookup to the current file to insure that
> 14 	  if:								(this #
> hasn't been used and some other checks
> 	 then: purchase_order_number=po_num	
> 15	  if:
> 	 then: emm(10)= purchase_order_number+"1";wrtie emm
> 16	  if:
> 	 then: created_by=getenv("username")
> 17	  if:
> 	 then: SHOW "";display;end				'move to store #
> field
> 
> After having a problem with this code failing to work properly, I ran some
> tests.
> 
> On the serve I have both the production system and a development system.  I ran
> the following test using the development system only.
> 
> 1. Opened a work session to the order entry module
> 2. Opened another session to display the master file record 1 with the next
> order #.
> 3. Went into add new orders from the order menu
> 	a. Pressed enter from field 1, the first field entered, got a new order
> #
> 	b. Cursor in store # field, changed to master file session and pressed
> "X" to exit record.
> 	   Received a message that the record was locked by another process.
> 4. Returned to order entry screen and entered a store # and verified the proper
> store.
> 5. Repeated step 3 with the same results
> 6. Returned to order entry session and placed a quantity in the quantity field
> and pressed <enter>. This placed the cursor in the item # field.
> 7. Repeat step 3- this time the record was unlocked and I was able to exit to
> the menu.
>   	 
> Change the posting line to:
> 15	  if:
> 	 then: emm(10)= purchase_order_number+"1";write emm;sync emm
> 
> Repeated the above steps with the same results.
> 
> Changed the line again:
> 15	  if:
> 	 then: emm(10)= purchase_order_number+"1";wrtie emm;sync emm;close emm
> 
> Repeated above steps, this time the record was unlocked right away.
> 
> I added the code the yesterday and since then there have been no problems.
> However, one never knows.
> 
> There is some additional code for insuring (or at least trying to insure) that
> no order number is duplicated and that the correct "next Order #" is used.
> 
> Closing the master file doesn't cause any problems as most of the time is spent
> entering order details which can take from 1 to 10 minutes or more depending on
> the number of items being ordered.  
> 
> I mentioned this problem in the "chat room" and Nancy advised that she had seen
> a similar problem on Novel.  But this proved to be a write cash problem and was
> solved by using a short sleep before moving on.
> 
> This didn't seem to be my problem as I sat in the store # field for a few
> seconds before switching sessions and testing the exit from the master file.
> 
> Has anyone else, besides Nancy, seen this problem?
> 
> Richard Kreiss
> GCC Consulting 
> 

I saw a similar situation years ago running windows ?? over a lantastic 
network. I believe that I set PFSYNC to ON or ALL in filepro and did 
something to the network also to cause it to write the cache after each 
transaction was saved at the workstation. I could never go back and find 
what it was because it was so long ago but it definitely had to do with 
network and/or windows holding transactions in the cache until forced to 
write them to disk.

> 
> 
> 
> 
> 
> 	  
> 	  
> 
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> .
> 



-- 
William Akers
MGM Industries, Inc.
Hendersonville TN USA