Next Number restarted at 1

chayang

Member
In our test environment, when I entered in a non-stock PO Requisition the order number restarted with 1 instead of using the next number. I entered another non-stock PO and it assigned an order number of 2 and so on.

In DV and PD, it is assigning the correct next numbers which is around 1300.

Has anyone seen this before?
 
Next Numbers are Environment-Specific. If your Test Environment is brand new - it should start at 1.

Where-as, the other environments have been hammered a little more - they are significantly higher.

Daniel
 
Hi All,

we have just started getting a similar problem in one of our custom apps. When the X0010 Next Number is called we are passing only 2 parms ( System [59] and Index [01] ) and the next number is returned. All the other parms are not defined. This is working in 99.9% of cases but there is one situation where the X0010 routine does not return a number from NN 59/1 and instead uses the next number by company table (F00021) and actually creates a record in F00021 with a blank company number and a doc type of '1'. Here is the log:


May 29 12:01:30 ** 5892/4840 Entering JDB_OpenTable( Table = F0002)
May 29 12:01:30 ** 5892/4840 Entering JDB_OpenTable( Table = F00021)
May 29 12:01:30 ** 5892/4840 Entering JDB_FetchKeyedForUpdate
May 29 12:01:30 ** 5892/4840 ODBC:I DBInitRequest(new)
conn=040F4F18 hd=05530D70 dr=055594C8 FITAMAS3 A (JDE@Business Data SWE - AWS)
May 29 12:01:30 ** 5892/4840 SELECT * FROM XTASWEDT/F00021 WHERE
( NLKCO = ' ' AND NLDCT = '1 ' AND NLCTRY = 0.000000 AND NLFY = 0.000000 )

FOR UPDATE OF NLN001
May 29 12:01:30 ** 5892/4840 Entering JDB_UpdateCurrent
May 29 12:01:30 ** 5892/4840 ODBC:I DBInitRequest(new) conn=040F4F18 hd=055327A0
dr=055594C8 FITAMAS3 A (JDE@Business Data SWE - AWS)
May 29 12:01:30 ** 5892/4840 UPDATE XTASWEDT/F00021 SET NLN001=1.000000
WHERE CURRENT OF C40FA7F8


The next number constants (GCN001) in F0009 is set to '1' so we understand that it will create a record in the NN by company table under certain conditions, but this isn't one of them!

The weird thing is that this problem only happens when using our test data. The same application works ok in dev and then 'fails' if pointing to our test data.

I have checked OCM mappings and there are no overrides on the F0002 or F00021 tables. The same problem is produced on fat client and on Citrix Terminal server. The problem started happening about 3 weeks ago but before that time it worked ok.

Does anybody have any ideas please?

Andrew Holder

OW Xe base, SP21, AS400 V4R4, W2000 TSs, Citrix
 
Back
Top