Why numbering object looking back?

[former_member194142]

Hello I have created a Numbering Object via SNRO tx, z_my_numb_obj, its details are as below,

To-year flag: Not checked

Number length domain: NUM6

No interval rolling: Not checked

Warning %: 0.0

Main memory buffering: Checked the check box              

No. of numbers in buffer: 10

Intervals:

No.------------------ From #............To #............Current #.......................Ext.

01-------------------- 000001........... 999999........ 803..............................Not checked

Originally I thought it was sequential, i.e. within a rang, the ids sequentially increase.

Last week all the documents created by me were 106, 107 and so on, it stopped 121

Today, I noticed that Documents numbers started 14, 15 etc., like if numbering was sort of reset and restarted.

Could you please explain,

1) Why numbers went back from 106, 107.....121 to.... 14, 15.....strange!

2)  Same # cannot be assigned twice, i mean, kind of duplication?

3) How numbering object works actually? i thought if it missess some # (like, 14, 15 in this case)....then, i thought numbering object never reverts back/looks back/assigns a pas #s, is not correct?

Thank you

[SuhaSaha]

Main memory buffering: Checked the check box  

Did you read the F1 documentation of "Main memory buffering"? Read it you will find the reason for this behavior. <My bad i misundestood your question >

Afaik if the buffering is turned on & a number is lost, it is lost for good. This results in gaps in numbering & hence should not be used if you require sequential numbering.

Only thing that's coming to my mind is: "Did someone change the number range interval?"

BR,

Suhas

Message was edited by: Suhas Saha

[former_member194142]

Thank you.

Nobody has changed the interval, am sure.

OK, as a layman i expected it as a SEQUENTIONAL numbering, but, its OK, i mean, its NOT necessory for us to have it/generate as sequential numbering.

Any clues for my original questions?

Thank you

[alex_campbell]

Regarding your original question:

Normally (when buffering is turned off) the next number to be used is stored in the database, and whenever a number is needed that databse record is locked, the number is incremented, and returned to the program which requested the number. When buffering is turned on, the next number to be used is stored on the app server instead of in the database. Essentially, instead of generating a number from the database on demand, each app server is issued a set quantity of "next" numbers (in your case 10) when they come online, or when they run out of buffered numbers. This way the numbers are still unique (each unique number is only issued to one app server). As a consequence though, if app server A is issued numbers 11-20, and app server B is issued numbers 21-30. The next number you generate depends on which app server you're on. If you're on app server A it will be 11, if you're on app server B it will be 21. Hence, you cannot depend on the numbers bieng sequential. Also, If one of the app servers has it's buffer cleared before it uses all of the numbers, than those numbers are lost. Hence, you cannot depend on the numbers bieng contiguous.

Regarding your problem:

I know it's a long shot, but since you have buffering turned on, if one of your app servers was going on and off, it could have consumed numbers 20-100. For example:

App server A is issued numbers 11-20.

App server B is issued numbers 21-30.

App server B is restarted, and so it is issued numbers 31-40.

App server B is restarted again, and again, and so on until...

App server B is issued numbers 101-110.

At this point, if you were generate a number on App server A, you would recieve 11, but if you were to generate a number on app server B, you would recieve 101.

In fact there may be other, more likely scenarios where the app server's buffered numbers are cleared and it is issued new numbers. That's where I would focus my attention.

[former_member194142]

Thank you for your detailed & awesome explanation.

1) Last question pls., pls. let me know in my case (with the above said settings) that is it guaranteed that NO DUPLICATION gonna occurs (i mean, system is issuing same number twisce to my custom progrm), if so, my custom table updation will results in DUMP!?

2) In general, what would you suggest me whether BUFFERING on or off?

My purpose is: User enters the data on the adobe interactive form and submits, now as soon as user clicks the SUBMIT form, i need to generate a number and assign this number to the form and make it as an entry in a custom table

Thank you    

[SuhaSaha]

Hello ,

Another reason for the "buffered" Number Ranges(NR) not generating contiguos numbers is that if the transaction using the NR rollsback and the numbers generated are lost for good. Imo this contributes most towards buffered NRs not being contiguos.

Anyway nice "educated" guess What baffles me the most is the duplication of the numbers generated by SAP. Afaik SAP NR mechanism is designed in such a way that duplication should not occur. But in the case of OP, duplication occurs

- 

its NOT necessory for us to have it/generate as sequential numbering.

You can live with the buffering then.

BR,

Suhas

[Former Member]

Hi Suhas,

What is OP? In both the case, I dont feel there will be a duplication of numbers from NR.

Can you tell me why this will happen?

Thanks,
Shambu

[SuhaSaha]

Hi Shambu,

Lol, OP = Original Poster

Yes, that's true whether Buffering is turned on or off duplication should not occur from the NR. But for the OP it happens I'm not sure why this is happening as well.

BR,

Suhas

PS - There was this WiKi with the details of the common abbreviations used in SCN world. Sorry i don't have that bookmarked.

[Former Member]

Suhas,

I feel your reply of referring to documentation regarding number range is still valid.  AFAIK, in case of multiple application servers this is possible with buffering in each server. 

The number interval buffer is in the Shared Memory of the application server. Each buffer is used to store the external number intervals and a certain number (subinterval) of the internal number intervals. If the numbers of an internal number interval are used up, numbers are taken from the database via the number range server. The status of the number interval in the database is increased by the number of numbers fetched to the buffer.

I think, OP didn't mentioned number were duplicated.  His question is in the above scenario, whether the numbers will be duplicated ?

Correct me If I misunderstood the scenario.

Regards, Vinod

[SuhaSaha]

I think, OP didn't mentioned number were duplicated.

Hell yeah!! You're right

I was confused by the OP's query on NR duplication not once but twice

2)  Same # cannot be assigned twice, i mean, kind of duplication?

1) Last question pls., pls. let me know in my case (with the above said settings) that is it guaranteed that NO DUPLICATION gonna occurs (i mean, system is issuing same number twisce to my custom progrm), if so, my custom table updation will results in DUMP!?

Sorry for confusing the entire lot & good observation Former Member!

Cheers,

Suhas

[ThomasZloch]

Suhas Saha wrote:
PS - There was this WiKi with the details of the common abbreviations used in SCN world. Sorry i don't have that bookmarked.

http://wiki.sdn.sap.com/wiki/display/HOME/SCN+Urban+Dictionary

(some information/links not up to date, but still quite funny)

Thomas

[Former Member]

Hi Raju,

Please take a look at this note.

Note 62077 - Info: Internal number assignment is not continuous

As it says in the note, the buffering can be switched off if you want continous allocation.

The downside to that is frequent database acces for getting the next number in the range.

If you can live with that, switch to 'No buffering'.

Even in both conditions, with or without buffering, there will be no duplication of number from the range.

As Alex has clearly mentioned in his example, that if Appserv1 is issue 10 - 20, the Appserv2 is allocated 21-30 in the buffer: it cannot overlap.

Thanks,

Shambu