Kurt, Personally I would do away with the rlock() and replace commands and use sql update statements with the relevant method of buffering. Take a look at Andy Kramek's discussion on the subject:
http://weblogs.foxite.com/andykramek/archive/2005/10/18/948.aspx or http://tinyurl.com/yld8ka8 I have used Rlock() and Flock() in the past with very few problems but the SQL route is more consistent with the VFP locking thinkset. Also I would seriously look at whether the Disk Caching for writing is disabled on the server if that is where you are getting the data from. What may well be happening is that the VFP program may be throwing data at the server faster than the old DOS software, hence the possibility of data conflict. The other solution is to Flock() the file and only allow access as required in the equivalent of single user mode but this may well slow the process up. You will find that the Flush command is in fact redundant when using a server configuration. http://www.west-wind.com/wiki/wc.dll?wc~TableBufferingProblemsWithVFP or http://tinyurl.com/yzjchqk Dave Crozier -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kurt Wendt Sent: 03 February 2010 14:54 To: [email protected] Subject: Sequence Control # Problem! Hey folks, One of the users of our system has recently started having a problem (and they recently switched from our older DOS based system to the newer VFP based system - even though the VFP system is still DOS looking with the same color scheme and fonts). The problem is that they got a duplicate Purchase Order # and previously a duplicated Invoice #. This has happened like 3 or 4 times over the past several months. They are getting so desperate and frustrated with our system (due to other problems as well - but, this problem is a SERIOUS one - and it makes the system look Very Unreliable) - that they are ready to demand their money back for the upgrade from the DOS to the "Windows" system - and go back to using the DOS system. I personally looked at the Procedure that generates the Seq Control #'s - and I didn't really see anything wrong with it - and its small and should run fast - and doesn't seem like it Should be having this problem. But, its happening anyway. Of course, we are even considering that it MAY be due to hardware problems on the client end. So - here's the deal. We have a Sequence Control file (SeqCtl.dbf) - with a single record that contains 51 different fields. I just took a closer look at that file - and some fields are not sequence #'s - but, other info - with about ½ or more of the field being Sequence #'s. In the past - another client experienced the problem. And, back then - someone here implemented a solution of taking out 1 or a couple of the fields and putting them into a Separate DBF file(but, it was done as a Customization for that one client). And, this request has now been made for me to do the same thing - for this current client - but also to our Base system. They want me to pull out the Purchase Order, Sales Order and Invoice numbers - each to a separate DBF file. And, that is what I am working on this morning. But, in the meantime - I was wondering if someone could take a look at the code below to see if there is any KNOWN VFP issue in the code that would cause such a problem. Any help would be GREAT appreciated. TIA, Kurt *-*-*-*-*-*-*-* * [SEQCTL] ************************************************************************ PROCEDURE SEQCTL ************************************************************************ PARAMETER PARM PRIVATE XVAL, XCLOSE, XALIAS XALIAS = ALIAS() XCLOSE = .F. IF .NOT. USED('SEQCTL') SELECT 0 USE (QDD+'SEQCTL') XCLOSE = .T. ENDIF SELECT SEQCTL CLEAR TYPEAHEAD DO WHILE .NOT. RLOCK() XL = INKEY(1) ENDDO GOTO RECNO() STORE '' TO XZVAL, XVAL DO CASE CASE "INVOICE" $ PARM XVAL = IIF(&PARM <1000000, &PARM+1, 100000) XZVAL = ZSTR(XVAL,6) IF INVOICE = NFINVOICE REPLACE INVOICE WITH XVAL, NFINVOICE WITH XVAL ELSE REPLACE &PARM WITH XVAL ENDIF CASE "PONO" = PARM XVAL = IIF(&PARM <100000, &PARM+1, 10000) XZVAL = ZSTR(XVAL,5) REPLACE &PARM WITH XVAL OTHERWISE XVAL = IIF(&PARM <1000000, &PARM+1, 100000) XZVAL = ZSTR(XVAL,6) REPLACE &PARM WITH XVAL ENDCASE UNLOCK FLUSH IF XCLOSE USE ENDIF IF !EMPTY(XALIAS) SELECT &XALIAS ENDIF RETURN(XZVAL) *------------------------------ END SEQCTL ------------------------------ --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/5a03096641a74453965d5acc00334...@develop ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
