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.
0
Comments
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.
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
"Never memorize what you can easily find in a book".....Or Mibuso
My Blog
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?
an interesting (but not advisable) alternative is to use negative entry nos.
anyway, I would go for the first alternative..
"Never memorize what you can easily find in a book".....Or Mibuso
My Blog
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.
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.
=D> =D> =D>
Holy crap, you should write a blog about this.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
Or a book
Actually yes I think the forums are not the right place to express this. Blog is more appropriate.
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.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
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".
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.
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.