Gregory@2014
20th October 2014, 10:15
Hi
We use BAAN IV and are experiencing a problem where one of our series are constantly full. We archive on a regular basis and when we 'Maintain First Free Number" for the particular series, BAAN does not seem to release the archived number in the live company.
Any suggestions?
Greg
benito
20th October 2014, 15:15
Did you try setting Blocked for Input to Yes?
Gregory@2014
21st October 2014, 10:14
Benito
How will this help?
See attached for our current set up. I am trying to free up the 6 series as the other series are dedicated to something else.
vamsi_gujjula
21st October 2014, 12:36
since this is post on first free .. i wanted to extend it to .... resolve my doubt too..
tcmcs.dll0050.check.and.generate.order.number Vs tcmcs.dll0050.read.and.update.first.free.number
What is the diff between these 2 dlls ?? when to use which one and what is this cache functionality
IS it like one updates the first free no. other updates as well commits the first free no??
vamsi_gujjula
21st October 2014, 13:12
Never mind:
To improve the performance of sessions in which new order numbers are assigned, you can define a cache size for a series. The cache size is the number of new series numbers that ERP LN generates at once. If there are series numbers in cache, users do not have to wait while ERP LN generates and checks the next series numbers.
Allowed values
Cache size = 0
No caching is applied. If you request a new number, the number is only committed after the transaction to which the number applies is completed.
Disadvantage: The number series is locked during the transaction. Other users cannot request a new number from the same series until the transaction is completed.
Advantage: No numbering gaps.
Use a cache size of 0 if number gaps are not allowed. Preferably, request a new number close to the end of a transation to reduce locking time. In high volume implementations, a cache size of 0 may cause performance and locking issues.
Cache size = 1
If you request a new number, the number is committed immediately, even if the transaction to which the number applies is not yet completed.
Disadvantage: Numbering gaps may occur if a transaction is not finished.
Advantage: The number series is locked for only a short time, which improves performance.
A cache size of 1 is the default value for number series. In this way, performance and locking issues in high volume implementations are avoided as much as possible.
Cache size > 1
The value of the cache size indicates how many new numbers are requested at once. The numbers are committed immediately, even if transactions are not yet completed.
Disadvantage: Large numbering gaps may occur if more than one transaction is unfinished.
Advantage: The number series is locked for only a short time. Furthermore, for all numbers that are requested, the number series needs to be updated only once, which improves performance.
A cache size larger than 1 is only recommended if a cache size of 1 does not solve locking issues sufficiently.
benito
21st October 2014, 15:10
gregory, nope it won't help. misunderstood...but...once you have archived, what happens if you reset the number in series 6?
vamsi, he's on baaniv. the dlls don't exist and their is no field for cache.
Gregory@2014
22nd October 2014, 10:09
Hi Benito
From what I gathered, we got someone in to set up a second archive company which we use at the moment. It looks like once we used a number in the live company and archive it, it is not available for use again (in the live company).
The reason why we archive is so that the numbers is available to use again as we place hundreds of orders per day and our series becomes full quickly.
Also, when you archive once and the series becomes full abd you archive again - does it over ride the existing info in the archive company? (if the same number that you are archiving already exisits in the archive company)
Regards
Greg
benito
22nd October 2014, 16:03
are you getting an error? i checked my old notes in IVc and didn't seem to have that issue. can you try querying your table tisfc001, max.pdno = select max(t_pdno). then you can manually set your first free number to max.pdno + 1.
yes it will override the existing info in the archive company. that's the reason why it's a good idea to create a new backup company for each year. bottomline it depends on your company's archiving strategy.
Gregory@2014
23rd October 2014, 09:00
I will try that and let you know
Thanks for help
Greg