**
Many thanks to Conny for the workaround. But I am afraid that won't
help.
Because I still need the tickets created for this year until 31 Dec
2008 as the actual format.
Maybe I can somehow schedule this. But I am not sure whether that's a
best way to deal with the problem.
And on top of that every year I need to redo the manip. Also changing
by hand the 2009 for 2010....
But at least the trick is a great start point for me to get more
familiar with the Data Dictionary. Probably I'll find my way out of
this puzzle.
However please do not hesitate of you have a better idea. Or more tips
Many thanks
Serouche
Joe D'Souza wrote:
**
Martin just
explained what has to be done.. and he pointed out the right table. I
thought it was the field_dispprop that had the column defaultvalue.
Sorry for
pointing out the wrong table name but I wasn't in front of a AR Server
database to verify my notes to you..
Cheers
Joe
**
Serouche,
following should do the trick
update arschema set nextid = 1
where name = 'your form name'
update field set defaultvalue =
'<some string>2009' where fieldid = 1 and schemaid = (select
schemaid from arschema where name = 'your form name')
after that you have to issue
arsignal -g your_server_name This causes the arserver to recache all
the form and field definitions from the database.
Kind Regards Conny
PS: you should test this
procedure before using it on a production box
** right now the Request_ID of my form has a default set to <some
string>
The ID's are at the moment in the following format:
<some string>20080370, <some string>20080371, <some
string>20080372, <some string>20080373, ...
Let say the last ID of December 2008 will be <some string>20080380
Then the first ID of 2009 will be <some string>20090381
I'd like to avoid this.
I'd like to have <some string>20090001 for the first ID of 2009
So thank you for the arsignal but again I don't see how I should use it.
Direct SQL to update the field_dispprop table ? Is that what you meant?
With a Run Process for arsignal at some time? Before or after the
Direct SQL?
Could you tell me more?
Thanks
Serouche
Joe D'Souza wrote:
**
Would you be
a little more specific as to what you mean by saying 'flip my
Request_ID' ?
I have so
far understood you need to change the prefix. That can be done with a
Direct SQL to the database table field_dispprop to change the default
for that schemaid.
Joe
** Joe,
many thanks for your tips.
However, I still do not see how to built something to flip my Request_ID
I created 2 triggers to update my T and H tables on insert.
I noticed the API was somehow building the ID but nothing got inserted.
So I am wondering whether now I need to combine my triggers with the
arsignal or do I need something else?
I don't really see how I should use the arsignal. I am not refering to
the syntax.
Could you help more please?
Thank you
Serouche
PS: and I am on ARS 6.01
Joe D'Souza wrote:
**
Serouche,
Use it
in an Escalation in a Run Process if the change to the default prefix
is at a definite interval after changing the prefix using a Direct SQL
Syntax:
/install/path/of/your/application/bin/arsignal
-g <hostname>:<port number if applicable>
If the
change in prefix happens on an event rather than a interval, try
creating a form and set an entry to it on that event that triggers the
above..
Cheers
Joe
** Thank you Joe,
This seems to be fine. Tickets in that schema are not created that
often.
But I don't really see how I could use the arsignal in my flow ...
could you tell me more please?
Thank you
serouche
Joe D'Souza wrote:
**
What
exactly do you want your Request Id to be?
The
Run Process you thought might help as Martin pointed out is to convert
internal meta data that represents run if qualification into what you
see in the Admin too and vice versa.
Dynamically
changing prefixes of Request ID's can be done provided you recache the
definition immediately after triggering the change in the default value
of the prefix. You can do this using the arsignal command with the -g
switch.
Having
to recache the definitions obviously mean you cannot do it too often
(like every 5 minutes) because it would hammer your performance..
Cheers
Joe
** I just tried your idea. I get the following:
Next available ID produces an Entry ID that overflows Entry ID field --
contact the Administrator (ARERR 305)
This is probably because we already have 8000 rows in the form.
The idea is to have every year <some string>YEAR0001, <some
string>YEAR0002,<some string>YEAR0003,<some
string>YEAR0004, ...
So right now what I do is every year after the first ticket is created
I export the row in a arx format. I manually make the change. Then
import with the import tool.
And this way the next id gets the right format. And we are safe for the
rest of the year.
But I'd like to have this self-service by Remedy itself.
I am starting to doubt in the power of this tool. So it has at least
one limitation.
Conny Martin wrote:
**
this
special run process wouldn't help you.
Documentation
says: "Converts an internal representation of a qualifier into a
qualification string using ID format. "
It
deals with qualifiers not request_id formats.
What
about setting the Default-Value of the request_id field to <some
string>YEAR ? You have to adjust this every year, but it's simple.
Kind
Regards Conny
** Dear listers,
some of my users would like to have a fancy Request_ID in the following
format:
<some string>YEAR<Id number in 4 digits>
After many unsuccesfull attempts, I believe the Process Application-Format-Qual-ID could help
The problem is I don't get it work.
Could somebody give a hint on how to use this Process?
Or simpler, if anybody has a better idea, please share.
Thanks
Serouche
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___
|
