If you use web services to create records(complex schema with partent and child), a failed creation will not rollback the already "taken" entryid´s in the child schema.
-- Jarl On 2/9/07, Hugo Visser <[EMAIL PROTECTED]> wrote:
** I can also see the reasons why they did it the way they did, but that doesn't mean I'm satisfied with it :) I know about the missing nextid's when a transaction is rolled back, imho a rollback should also rollback the nextid. But a rollback would also be something that happens due to an error such as a database timeout or something else "serious" and unexpected, while a server restart may be scheduled and controlled. Hugo On 2/9/07, Hall Chad - chahal <[EMAIL PROTECTED]> wrote: > ** > > > > I can see reasons why they did this. To keep track of where it left off they would have to write the real last ID somewhere (file, arschema table, etc). If AR Server loses its DB connections or crashes it might not be able to update the arschema table. It could probably write to a file, but that's probably not the best way either. I do wish they would write back to the database during a proper shutdown though, even if crashes go unhandled. > > > > By the way, even in 5.x and 6.x you can still have missing IDs. All it takes is an error on a push field action during a submit. In those cases the next ID is already incremented but the actual submittal is rolled back. So that ID will never be used. > > > > > Chad Hall > (501) 342-2650 > > ________________________________ > > From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Hugo Visser > Sent: Friday, February 09, 2007 7:21 AM > To: [email protected] > Subject: Re: Next-ID-Block-Size - Skipping Numbers > > > > ** Well, I disagree. If the server is gracefully stopped (not crashing or some other exceptional event) I'd expect that after the next startup the next ticket number would be just the increment of the last ticket number. The fact that it's not...I think it's poor design. I understand that the way it is implemented now is the easiest way to implement it in the existing design. But for some shops that have to account for each "missing" ticket this feature is useless. > > Hugo > > > > On 2/9/07, Rick Cook <[EMAIL PROTECTED]> wrote: > > ** > > > This is simply functioning as designed, Stephen. When you allocate a chunk and it is taken, the nextId variable is reset at that time to N + <chunk size>. When the server restarts, that's the next ticket number, regardless of what happened to those preceding it. Plus, how would it know whether the Entry IDs allocated were never used, or were used and then deleted? > > > > > Rick > ________________________________ > > From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, Stephen > Sent: Friday, February 09, 2007 5:40 AM > To: [email protected] > Subject: Re: Next-ID-Block-Size - Skipping Numbers > > > ** > > > Wow. I am curious as to how this is a benefit. Does anyone know why BMC designed it this way [that each time you restart the server it skips Request ID numbers]? There must be some benefit, I just can't see it. > > > > > > Stephen > > > > ________________________________ > > From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Hugo Visser > Sent: Friday, February 09, 2007 5:04 AM > To: [email protected] > Subject: Re: Next-ID-Block-Size > > > > ** There's one thing that you have to know when working with this feature. If you restart the server the "reserved" block gets lost for ever. So when you start with a fresh form, and have reserved 1000 entry id's, the first entry id will be 000...1. If you restart the server 999 entry id's ar e "lost" so the new next entry id (the second ticket in the form) would be entry id 000001000 and not 00000..2. > > Hugo > > it___ > > __20060125_______________________This posting was submitted with HTML in it___ > > > __20060125_______________________This posting was submitted with HTML in it___ > > > __20060125_______________________This posting was submitted with HTML in it___ ************************************************************************* > The information contained in this communication is confidential, is > intended only for the use of the recipient named above, and may be > > legally privileged. > > If the reader of this message is not the intended recipient, you are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited. > > If you have received this communication in error, please resend this > > communication to the sender and delete the original message or any copy > of it from your computer system. > > Thank you. > ************************************************************************* > > > __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
