Item Ledger Entries, Entry No.

vincentchua

As noted, Item Ledger Entries, Entry No. is a Integer, (-2,147,483,648 -> 2,147,483,647).
Has anyone encountered, running out of Entry No.?
What will happen if the Entry No. ran out?
Can the Entry No. be reused? How to re-use the Entry No.?

Thanks.

Snoopy

I can state for any Navision-user, developer etc., the Entry No. will never run out, be sure.

vincentchua

Item Ledger Entries, Entry No. is a Integer, (-2,147,483,648 -> 2,147,483,647).
The current design by our Vendor, for every transaction/ posting made, there will be minimum of 6 entries being posted into the Item Ledger.
Our last Item Ledger Entry, Entry No. is 84,931. after a short period of about 7 months.
2 months down the road, we are anticipating huge volume, Hence, i am quite worried.

Please help advice
1) What will happen if the Entry No. ran out?
2) Can the Entry No. be reused? How to re-use the Entry No.?

Thanks.

Belias

84,931/7 = 12133 entries x month

2,147,483,647/12133 = about 176995 months before running out of entry nos.

176995/12 = about 14749 years

...running out of entry nos. will be the last of our problems in year 14749

bbrown

I'm working with a customer that generates 1.7 million Value Entries each month. Even at that rate, it will be over 100 years before entry numbers run out in that table.

vincentchua

Thanks. That will ease my worries.

However, just to satisfy my curiosity,
1) What will happen if Item Ledger Entries run out of Number.
a. According to Standard Navision CodeUnit 22, It will take the Last Entry No., increment by 1.
b. Since Entry No. in Item Ledger Entry is a Primary Key, Error will occur.
2) Is there a way to continue using Navision?

Belias

save balance values, migrate them with a single entry on a clear db together with master data etc. and continue to work.
an interesting (but not advisable) alternative is to use negative entry nos.
anyway, I would go for the first alternative..

David_Singleton

vincentchua wrote:

Thanks. That will ease my worries.

However, just to satisfy my curiosity,
1) What will happen if Item Ledger Entries run out of Number.
a. According to Standard Navision CodeUnit 22, It will take the Last Entry No., increment by 1.
b. Since Entry No. in Item Ledger Entry is a Primary Key, Error will occur.
2) Is there a way to continue using Navision?

Why not just try it, its quite simple, just create some big item journals and post them. Also could you help all of us by letting us know the results.


PS I wont actually be here by the time you finish the testing, so I will let my daughter know to ask her great grand children to come back to MiBuSo and check what the result will be. happy posting.

David_Singleton

On a more serious note, when I first started in Navision we had a partner who's customer asked a similar question. The customer had one of those genius developers that knew basically everything, (though he never actually had seen blue sky or green grass in his life) and was really angry that their NSC was telling them that they could have an unlimited number of customers vendors items and transactions, since as a programmer he knew that everything had limits.

we did some extrapolations that showed that even with the fastest hardware available it would take about 1,500 years for them to be able to create enough data reach the limits, but anyway they would long before run out of space in the system and have a hundred other issues to deal with more significant than the definition of infinity. With today's technology, NAV can post about 100,000 sales lines a day on pretty standard hardware, so reaching the limit could theoretically be done in 70 years or so. The drop from 1,500 to 70 years is a result of faster hardware, so in fact it would never have taken 1,400 years, just like now it wont take 70 years. So of course the limit can be reached.

But I think Belias points out the key issue. This is really a red herring; you will have so many other issues to worry about before that day ever comes close. Its very important to focus on real issues and not silly things that distract from reality.

In the past we had Navision business consultants that became pretty good at developing in C/SIDE. These days we have pretty good developers that really have no desire to understand business and the real world. Questions like this show where this product is headed unfortunately.

Alex_Chow

David Singleton wrote:

In the past we had Navision business consultants that became pretty good at developing in C/SIDE. These days we have pretty good developers that really have no desire to understand business and the real world. Questions like this show where this product is headed unfortunately.

=D> =D> =D>

Holy crap, you should write a blog about this.

David_Singleton

Alex Chow wrote:

David Singleton wrote:

In the past we had Navision business consultants that became pretty good at developing in C/SIDE. These days we have pretty good developers that really have no desire to understand business and the real world. Questions like this show where this product is headed unfortunately.

=D> =D> =D>
Holy crap, you should write a blog about this.

Or a book

Actually yes I think the forums are not the right place to express this. Blog is more appropriate.

ara3n

I believe as any software becomes more and more popular and mainstream this will be an issue.
It's also due to globalization and different countries doing business differently.
In long run it's going to hurt NAV reputation because of bad implementations.
I don't know what can MS NAV can do.
Make it a requirement to pass NAV Financials before taking development? And don't make it a multiple choice test.

David_Singleton

ara3n wrote:

I believe as any software becomes more and more popular and mainstream this will be an issue.
It's also due to globalization and different countries doing business differently.
In long run it's going to hurt NAV reputation because of bad implementations.
I don't know what can MS NAV can do.
Make it a requirement to pass NAV Financials before taking development? And don't make it a multiple choice test.

Yes thats very true. Navision has been protected for some time now. Unfortunately as it moves to main stream this happens.

I used rentacoder recently to do a small php job. The quotes you get back are crazy. Basically people quote a random amount to try to secure the job, then post the spec on a few forums and wait ofr people to tell them how to do it. If it looks too complex they just vanish, if its doable they just wait till some idiot on a forum tells them how to do it.

Needless to say the code I got back was just junk and I had to throw it away.

I feel that with especially offshore developement right now, clients are sending a spec to their partner, the partner is sending it to 2 or 3 off shore companies and getting quotes, those off shore developers are just posting raw sepcs on mibuso and DUG and finding out how to do it.

There is no understanding or even desire to understand the business need, jut "WRITE SOME CODE TO FIX IT".

tripleDot

-2,147,483,648 to 2,147,483,647 is actually the range value of an integer for a 32bit computing.

You don't actually need to have an entry number exceeding that limit for you to have problems. I'm actually an Axapta user and I already have encountered one. My problem presented itself when one of our client issues cheque numbers that are 10 digits long and started with a 6. As you can see, this issue is actually not limited to Item Ledger Entries or Entry Numbers. As for solutions, I can only "think" of 3 for the moment...

1. a 64bit version of our respective software or a patch
2. customization by programming to override the use of integer type
3. device a plan on how to renumber you entries (or cheques)

FYI.

And oh... hello everyone.

bbrown

tripleDot wrote:

-2,147,483,648 to 2,147,483,647 is actually the range value of an integer for a 32bit computing.

You don't actually need to have an entry number exceeding that limit for you to have problems. I'm actually an Axapta user and I already have encountered one. My problem presented itself when one of our client issues cheque numbers that are 10 digits long and started with a 6. As you can see, this issue is actually not limited to Item Ledger Entries or Entry Numbers. As for solutions, I can only "think" of 3 for the moment...

1. a 64bit version of our respective software or a patch
2. customization by programming to override the use of integer type
3. device a plan on how to renumber you entries (or cheques)

FYI.

And oh... hello everyone.

First: Hello and welcome to Mibuso.

Now, first of all the limits of integer datatype have nothing to do with 32 bit vs. 64 bit computing. It's about the defined datasize of the datatype. The Int datatype is stored in 4 bytes and therefore can support the range of -2,147,483,648 to 2,147,483,647. The BigInt datatype is stored as 8 bytes and will support -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807.

To take this further the smallint datatype is stored as 2 bytes and supports -32,768 to 32,767. The tinyint is stored as 1 byte and supports 0 to 255.

Any of these are supported in either 32 or 64 bit environments.

In NAV check numbers (and other documents) are stored as 20 character code fields (SQL VARCHAR(20)) so that does not apply. I'm don't now about AX.

tripleDot

bbrown wrote:

Now, first of all the limits of integer datatype have nothing to do with 32 bit vs. 64 bit computing. ...

In NAV check numbers (and other documents) are stored as 20 character code fields (SQL VARCHAR(20)) so that does not apply. I'm don't now about AX.

If that is the case about the number range limit, then that is good news for me. The question now is how do we have NAV (or AX) use BigInt instead?

As for NAV's cheque number uses character instead of integer (or ENUM for AX), then that is good news for you.

Cheers.