Hi, Jens,

Yes, we have encountered AVALNUM locking issue in the past, and we have used database sequence type. In order to use database sequence type, I believe you need to pick a table that's been used by the function that uses this sequence number. Judging from you screenshot, you are creating a sequence number for workflow. I would try AWRKHISDES (Workflow history) table, and see if it works for you.

Also, as a couple side notes.

1. Database sequence type is using a unique sequence number that's attached to each SQL table. So you may not want to have two database sequence number setup using same table. Otherwise, they would be sharing the same sequence number

2. Since you can't really set what the "next" sequence number would be without going directly through SQL, you may want to give a different prefix than the previous sequence number setup (like the "XX" in your screenshot), so even if the sequence number itself overlaps with the previous sequence number, the document number would still be unique. 

3. An alternative solution to AVALNUM locking issue is to choose group type. In this setup, the system would still be pinging the AVALNUM table, but it would be less frequent as the system would grab a block of numbers at a time. This would not completely avoid AVALNUM locking issue, but would be less likely. 

Thanks a lot for your fast respons, Mike!

I think we will try your last suggestion, to use the Group type. Is seems simpler to use.
Then we don't even need to change any prefix in the sequence number, I asume Sage will continue to pick out numbers in "batch" starting from the last used one. Is that correct?

Do you have any experience for a suitable group size, I was thinking something like 10?

There are so many different tables involved in the Workflow, and some of them (like AWRKHISSUI) uses multiple Sequense numbers. Not sure how to set it up using Database Sequence then.

BR

Jens

Jens,

Yes, you won't need to worry about prefix in sequence number when you switch to Group type

Yes, I think 10 is a good group size. 

In terms of database type, in theory, the system doesn't care about which table it is. It's basically executing a uniqid([F:XXX]) commend to get the ID from the table. This ID is a SQL internal ID that does not impact the data in the table. However, the table needs to be available when it's assigning the sequence number. What do I mean by that? Technically speaking, at the beginning of any function, the system does not open connections to all the tables in the DB.  It only opens for those tables that the function needs. So to setup a database type sequence number for workflow, you need to assign a table that the workflow function would use so that the table would be visible to the workflow function when it needs to assign a new sequence number