Brian - it's a Good point. I actually caught that yesterday when I was reviewing the code (again - which someone else had written - as I would NEVER have put that in there like that - as it makes NO SENSE to do!). I also thought it would break the lock!
As such - I did already comment it out yesterday. Thanks, -K- -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Brian Abbott Sent: Wednesday, February 03, 2010 11:42 AM To: [email protected] Subject: Re: Sequence Control # Problem! Kurt Your code: ------------ DO WHILE .NOT. RLOCK() XL = INKEY(1) ENDDO GOTO RECNO() ------------ Not sure why that last line GOTO RECNO() is there? Would it not break the record lock you've established? On 03/02/2010 14:54, 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 ------------------------------ > > > > --- 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/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.
