I thought the Next-ID-Commit setting only made the retrieving of the ID from
the arschema table an independent transaction so if there is an error it does
not try to roll back. It does not alter the fact that the Request ID is not
available in the set fields actions of Phase 1 filters. In
Ni,
The Next-ID-Commit is not superseded, it still works.
If it is set to true (default in 7.6.04) it will update NextID and commit
it at the beginning of the API call, before the filters are run.
If Next-ID-Block-Size is set, Next-ID-Commit:T does not really matter,
does it, so in that sense
Hi Joe,
No, it does NOT wait for the commit any longer. At least not if you use
the Default-settings in 7.6.04.
The Unique-Index-error is fine to me. It means that the AR Developer did
something wrong.
Again, all your next arguments is voided by the fact that the default
setting is now
Haven't had the chance to play around with 7.6.04 too much as yet. So
haven't seen the impact of that default..
If it is already committed, how come its not available? Or is it available.
I might have missed something you said in your previous posts..
Joe
-Original Message-
From:
Hi,
No, it is not available. But if you look at the SQL logs, it is retrieved
and committed before the filters start running.
This option is available before 7.6.04, but it is not the default behavior
in earlier versions.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Hi,
Using arschema.nextId is not a good idea, as nowadays the default behavior
in 7.6.04 is to commit that value in chunks of 100, and pick from the
memory-based list within the AR Server process.
In the old days, when the request id was increased in steps of 1 without
any gaps, this would have
I think the reasoning behind keeping the nextid until after the request is
submitted is that the application waits for an actual commit before assuming
the nextID it has queried for as there is a less than a possible chance that
two or more users may attempt to submit a new request at the same
Mark,
If some external system is creating a ticket on your ITSM form, you can
trigger your workflows using the Request ID second time onwards.
Ex :
First : The external System creates a Record in the form.
Record is submitted and Request ID gets generated.
Second : The external System updates
Hello Listers,
someone is creating a ticket in my form. On submit I'd like to copy
the Request-ID into a field to in order to be able format it for
another purpose, but it's not working.
I've tried Set Fields: zzTmp_Request-ID = $Request-ID$ and
zzTmp_Request-ID = $LASTID$.
Any ideas how I can
$LASTID$ would not necessarily hold the current Request ID that is
generated. It holds the ID of a request that was last queried for. So if you
have workflow that did something like that, it may not necessarily be the ID
of your current request that was just created.
Use a filter to set the
Tried that Joe, but it's not working. And BTW, when you build a filter
that fires on submit and you push the newly created Request-ID into
another form, then the $LASTID$ does containt the request-id. I think
the only not-too-tricky option I have is to query the ARSystem
Metadata: arschema form
The Request ID is not available until Phase 2 in the filters. A usual method
is to do a push back to the form in an AfterSubmit Active Link action or in a
Submit Filter (Push to the same form where Push-If is '1' = $1$) to get the ID
into another field.
Fred
-Original Message-
From:
12 matches
Mail list logo
