Hey Frank - thanks for the reply. Actually - the command is in there - its: RLOCK().
Also - so you know - this is legacy/old code - not created personally by me. But, I'm the one that now needs to change it to hopefully prevent the problem. -K- -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Frank Cazabon Sent: Wednesday, February 03, 2010 11:15 AM Hi Kurt, I may have missed it, but I didn't see where you are locking the table before incrementing the value Frank. On 03/02/2010 10:54 AM, Kurt Wendt wrote: > 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 ------------------------------ _______________________________________________ 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/289ea162f5642645b5cf64d624c66a14071a1...@us-ny-mail-002.waitex.net ** 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.
