Hi listers,

sorry that I didn't answer earlier.
Thanks to all who have answered to my initial question.
I posted few (dummy??) questions to which nobody answered so that I was
a bit feeling like in ... Twillight Zone or something like this ...
This time my question raised so many ideas so I was back again to the
real world.
Anyway, to answer to everybody, I make it short:
1- the data comes from an internal source to the company but with
specific information needed only by one department.
2- it is produced everynight by the ADS.
3- we are still on Remedy 4 (very soon on Remedy 6)
4- by the time being to implement a LDAP connector between the ARS and
the ADS, I get a txt file
5- I convert this one into csv
6- I insert all data into my form.

Many thanks to Alvin, James, Daniel, Rick and the others for clear
explanations.
Finally I have a filter which runs on merge, if Email != $NULL and which
update/create the entrie. That works just fine.

I have another big concern which is the following:
- I am migrating form Remedy 4 to Remedy 6. Of course arimport tool is
nice to migrate also the data. Idea: put the database into read only.
Use arimport to migrate the data. Put back the database into normal mode.
I am just wondering whether this could not be done easily with some SQL
procedures on our Sybase server 12.5.3 ?!?!
No doubt Meta-Update is a nice tool, but my boss is not willing to give
me some money for it. And ASA I remember it does not run on Sun OS 5.9.
Is it?

Other new and fresh ideas are welcome !
:-)


Serouche Rahimpour
DCS Site Manager - Munich

Phone +49(0) 89-3200-6673
Fax +49(0) 89-3200-6898
Mob +49(0)176-2946-7484

http://www.dcs.ch



Ben Chernys wrote:

>Using Meta-Update as the import tool, it IS possible and easy to import
>based on ANY criteria that is unique to the form and can be expressed as a
>Remedy Query.
>
>For example, in the User form, say you want the full name field and email
>address to match before a new record will be created.
>
>With Meta-Update, you process each record of the import file and issue a
>query to determine the update record. If no records match you can create a
>record using different assignments. If one record matches it will update
>that record. It will skip the update (optionally overridden) if there are
>no data changes because of the intended update. If more then one record
>matches an error is declared.
>
>You may also chose only to create new records and skip updates of old record
>so that when you process a file only those record not matching will cause
>new ARS records to be created and those records matching will be skipped -
>though this is not needed as there will be no update when no data has
>changed.
>
>Further, you can get much more complex than this if you wish. For example,
>depending on the import data, the data in the update record, any other data
>records you may load in this process from any ARS servers, you can elect to
>update other tables as well. So for example, the import can update both
>SHR:People and User.
>
>Imports can be done as Merges (like the import tool) or Submits (not
>possible in the import tool).
>
>Please see www.softwaretoolhouse.com for more information or contact me off
>list.
>
>Ben Chernys
>
>Senior Software Architect
>Software Tool House Inc
>
>Canada / Deutschland / Germany
>Phone: +49 (089) 982 47935 GMT + 1
>Mobile: +49 (0162) 175 0956
>Email: mailto:Ben.Chernys@softwaretoolhouse.com
>Web: http://www.softwaretoolhouse.com
>
>A free notepad for Diary fields:
>http://www.softwaretoolhouse.com/downloads/DiaryFieldEditor.htm
>An ARS integration, import, batch facility:
>http://www.softwaretoolhouse.com/products/SthMupd
>
>-----Original Message-----
>From: Action Request System discussion list(ARSList)
>[mailto:arslist@ARSLIST.ORG]On Behalf Of McKenzie, James J C-E LCMC
>HQISEC/L3
>Sent: Wednesday, September 28, 2005 11:21 PM
>To: arslist@ARSLIST.ORG
>Subject: Re: somewhere ...
>
>
>Susan:
>
>Simple answer is no, you cannot import based on a different field than field
>id 1, and I don't think this will change anytime soon as field id 1 is the
>only field that will be unique on each and every form.
>
>James McKenzie
>Remedy Engineer
>C-E LCMC HQISEC, US Army
>L-3 GSI
>
>-----Original Message-----
>From: Action Request System discussion list(ARSList)
>[mailto:arslist@ARSLIST.ORG]On Behalf Of Susan Palmer
>Sent: Wednesday, September 28, 2005 11:26 AM
>To: arslist@ARSLIST.ORG
>Subject: Re: somewhere ...
>
>
>**
>No one asks where the new data is coming from.
>Could the user form entry id be inserted into wherever that data is coming
>from?
>Why does it have to be updated everynight?
>Is it external customers as opposed to internal staff?
>What are they logging into?
>
>Now I haven't looked this up but in v6+ can't you import based on another
>field other than entry id? I'm only on 5.1.2 and somehow I've been looking
>forward to that feature, although it might just have been a dream ...lol
>
>Susan
>
>
>
>
>On 9/28/05, McKenzie, James J C-E LCMC HQISEC/L3
> wrote:
>Rick:
>
>I would not try to do certain things with the User form, at least not
>directly. The indirect approach appears to be the best method for changing
>data in this form. I know that the User form is 'just another form', but
>delete your adminstrators and see what you have to go through to fix it.
>
>James McKenzie
>Remedy Engineer
>C-E LCMC HQISEC, US Army
>L-3 GSI
>
>-----Original Message-----
>From: Action Request System discussion list(ARSList)
>[mailto:arslist@ARSLIST.ORG]On Behalf Of Rick Cook
>Sent: Wednesday, September 28, 2005 10:45 AM
>To: arslist@ARSLIST.ORG
>Subject: Re: somewhere ...
>
>
>...and your point is...? There's nothing inherent in the User form that
>prohibits this action. If he's trying to re-import that which he deleted,
>he needs to:
>
>*
> tell his import mechanism to disregard the entry ID and just force
>the records into existing slots that may or may not match, or
>*
> find a way to map the entry ID and update the record appropriately,
>or
>*
> reset the nextID and pretend it's an initial install.
>
>If there are existing records (which, from the error msg, it appears that
>there are), then it should be pretty easy to see what they are and compare
>them to his import file, perhaps merge the two, and go from there.
>
>Of course, the Unique Index error may also be a product of a NULL value -
>duplicate NULLs will spawn that error, too.
>
>
>Rick
>
>
>
>From: Action Request System discussion list(ARSList) on behalf of McKenzie,
>James J C-E LCMC HQISEC/L3
>Sent: Wed 9/28/2005 10:02 AM
>To: arslist@ARSLIST.ORG
>Subject: Re: somewhere ...
>
>
>
>
>Rick:
>
>This is the USER form.
>
>James McKenzie
>
>
>-----Original Message-----
>From: Action Request System discussion list(ARSList)
>[mailto:arslist@ARSLIST.ORG]On Behalf Of Rick Cook
>Sent: Wednesday, September 28, 2005 9:54 AM
>To: arslist@ARSLIST.ORG
>Subject: Re: somewhere ...
>
>
>It sounds to me like that all he may need to do is reset the nextID back to
>1 for the import forms. It's easy to do, and the instructions are in the
>docs.
>
>
>
>
>
>
>Rick Cook * Senior Remedy Consultant * Denali Advanced Integration * (253)
>278-4112
>
>
>
>From: Action Request System discussion list(ARSList) on behalf of Daniel
>Hill
>Sent: Wed 9/28/2005 9:15 AM
>To: arslist@ARSLIST.ORG
>Subject: Re: somewhere ...
>
>
>
>
>I use SQL Server Data Transformation Services to pull data from remote
>sources into local database tables. The tables are then scanned against
>their corresponding Remedy forms to determine if the data needs to be
>updated. Each table has a RequestID column that is populated from a query
>against the Remedy form. If the RequestID column is NULL, then the record
>is exported to a new.csv file. If the RequestID is NOT NULL, then the
>record is exported to an update.csv file. There are then 2 jobs that kick
>off arimportcmd. 1 job imports using a Generate New ID mapping for the
>new.csv file. The other job imports using an Update Existing Record mapping
>for the update.csv file.
>
>With this method I don't have to worry about the system being unavailable
>while the data refreshes. While the SQL Statements within the DTS Package
>can be intense, it ensures that the workload required by Remedy is reduced.
>I have this running on 6 feeds currently and it works like a charm.
>
>P.S. - This method was used to overcome the Maximum Filter Operations I
>queried the list about the other week. After increasing the Maximum Filters
>I was happy with server utilization. It did, however, take 17 hours to
>process 60,000 of 300,000 records, during which time the Escalation Thread
>was tied up. Now the process runs in about 45 minutes and the escalation
>thread is only tied up for a few milliseconds. Thanks for everyone's input
>on the Maximum Filters.
>
>- Daniel
>
>-----Original Message-----
>From: Action Request System discussion list(ARSList)
>[mailto:arslist@ARSLIST.ORG]On Behalf Of Serouche Rahimpour
>Sent: Wednesday, September 28, 2005 11:37 AM
>To: arslist@ARSLIST.ORG
>Subject: Re: somewhere ...
>
>
>thanks again.
>I have another issue of this kind which is the following:
>- I have to update everyday the user form with new data.
>- data can be of course updated but it can be the same
>- the output is in csv format
>- my user form has one index on emails
>The problem is that when I use the arimport to import the csv file into
>my form, it always ask to generate new entry-ids. Which I don't want to.
>So every day I delete the whole data in the form. I then import the data
>and that works fine.
>Is there another way of getting round into this?
>I mean this must be something to set... maybe in the form or an AL...
>Any idea?
>
>
>Serouche Rahimpour
>DCS Site Manager - Munich
>
>Phone +49(0) 89-3200-6673
>Fax +49(0) 89-3200-6898
>Mob +49(0)176-2946-7484
>
> http://www.dcs.ch
>
>
>
>McKenzie, James J C-E LCMC HQISEC/L3 wrote:
>
>
>
>>Serouche:
>>
>>Did you delete the data through the Remedy User Tool or through SQL code
>>applied directly to the database?
>>
>>If it is the latter, it is possible that the database is out of sync with
>>the values stored in the Remedy database tables.
>>
>>If you deleted entries in the T table, you MUST delete the
>>corresponding entries in the B and h
>>tables as well as any data in any extended data tables.
>>
>>James McKenzie
>>Remedy Engineer
>>C-E LCMC HQISEC, US Army
>>L-3 GSI
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Serouche Rahimpour
>>Sent: Wednesday, September 28, 2005 5:11 AM
>>To: arslist@ARSLIST.ORG
>>Subject: somewhere ...
>>
>>
>>Hi listers,
>>
>>ARS 6.01
>>Sybase 12.5.3
>>Sun solaris 5.9
>>
>>I deleted data on the DB.
>>I try now to import data into my form with arimport tool.
>>No way. I get all the time " The value(s) for this entry violate a
>>unique index that has been defined for this form (ARERR 382)"
>>I can't get where these indexes are stored.
>>I though in some cache. So I restarted the server.
>>Nothing helps.
>>Will be anyone kind enough to give a help on that ?
>>Thank you.
>>
>>--
>>
>>Serouche Rahimpour
>>DCS Site Manager - Munich
>>
>>Phone +49(0) 89-3200-6673
>>Fax +49(0) 89-3200-6898
>>Mob +49(0)176-2946-7484
>>
>> http://www.dcs.ch
>>
>>
>>
>>
>
>
>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>
>
>
>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>
>>
>>
>
>
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>
>===================================================================
>NOTICE - CONFIDENTIAL AND PRIVILEGED - This e-mail may contain
>privileged and confidential information and is intended only for the
>addressee named above. If you received this message in error,
>please immediately notify the sender by return e-mail and delete the
>original message; any distribution, copying or use of this e-mail
>by you is strictly prohibited and may be unlawful.
>
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>
>
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>
>
>
>
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>This posting was submitted via the Web
>interface
>
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Alan, James et al,

You might want to experiment with the -e option of arimportcmd.

According to page 560-564 of the Advanced Guide for 6.3, -e will let you
specify a field ID to be tested for duplicate ID's. Assuming that the
case-matching issues have been resolved you could run arimportcmd -e 101
(and some other arguments for mapping and file name) to test the login name
field to be a duplicate entry instead of testing field 1, Request ID. When
field 101 determines that the incoming data is a duplicate record (or not),
then I assume that your mapping's behavior for updating the existing record
or creating a new one would apply. The field you choose should be unique and
ideally indexed (it has always bothered me that the User and group forms
have no indexes by default).

I haven't actually tried this yet, and there is minor historic precedent for
documentation being out of step with the tool's behavior, but I think this
should work.

If I had to solve this problem I would favor use of a staging form because
you can use workflow to clean up the data, format email addresses and so
forth, and to avoid the potential task of recovering Remedy administrator
accounts. If you import into the User form from (for example) a daily export
CSV from the HR department, you'd also need some mechanism to periodically
delete (or render useless) records that were not in the file. Presumably
those would be employees no longer with the company.

Doug Blair

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of McKenzie, James J
> C-E LCMC HQISEC/L3
> Sent: Wednesday, September 28, 2005 4:21 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: somewhere ...
>
> Susan:
>
> Simple answer is no, you cannot import based on a different
> field than field
> id 1, and I don't think this will change anytime soon as
> field id 1 is the
> only field that will be unique on each and every form.
>
> James McKenzie
> Remedy Engineer
> C-E LCMC HQISEC, US Army
> L-3 GSI
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG]On Behalf Of Susan Palmer
> Sent: Wednesday, September 28, 2005 11:26 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: somewhere ...
>
>
> **
> No one asks where the new data is coming from.
> Could the user form entry id be inserted into wherever that
> data is coming
> from?
> Why does it have to be updated everynight?
> Is it external customers as opposed to internal staff?
> What are they logging into?
>
> Now I haven't looked this up but in v6+ can't you import
> based on another
> field other than entry id? I'm only on 5.1.2 and somehow
> I've been looking
> forward to that feature, although it might just have been a
> dream ...lol
>
> Susan
>
>
>
>
> On 9/28/05, McKenzie, James J C-E LCMC HQISEC/L3
> wrote:
> Rick:
>
> I would not try to do certain things with the User form, at least not
> directly. The indirect approach appears to be the best
> method for changing
> data in this form. I know that the User form is 'just
> another form', but
> delete your adminstrators and see what you have to go through
> to fix it.
>
> James McKenzie
> Remedy Engineer
> C-E LCMC HQISEC, US Army
> L-3 GSI
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG]On Behalf Of Rick Cook
> Sent: Wednesday, September 28, 2005 10:45 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: somewhere ...
>
>
> ...and your point is...? There's nothing inherent in the
> User form that
> prohibits this action. If he's trying to re-import that
> which he deleted,
> he needs to:
>
> *
> tell his import mechanism to disregard the entry ID
> and just force
> the records into existing slots that may or may not match, or
> *
> find a way to map the entry ID and update the record
> appropriately,
> or
> *
> reset the nextID and pretend it's an initial install.
>
> If there are existing records (which, from the error msg, it
> appears that
> there are), then it should be pretty easy to see what they
> are and compare
> them to his import file, perhaps merge the two, and go from there.
>
> Of course, the Unique Index error may also be a product of a
> NULL value -
> duplicate NULLs will spawn that error, too.
>
>
> Rick
>
>
>
> From: Action Request System discussion list(ARSList) on
> behalf of McKenzie,
> James J C-E LCMC HQISEC/L3
> Sent: Wed 9/28/2005 10:02 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: somewhere ...
>
>
>
>
> Rick:
>
> This is the USER form.
>
> James McKenzie
>
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG]On Behalf Of Rick Cook
> Sent: Wednesday, September 28, 2005 9:54 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: somewhere ...
>
>
> It sounds to me like that all he may need to do is reset the
> nextID back to
> 1 for the import forms. It's easy to do, and the
> instructions are in the
> docs.
>
>
>
>
>
>
>
> Rick Cook * Senior Remedy Consultant * Denali Advanced
> Integration * (253)
> 278-4112
>
>
>
> From: Action Request System discussion list(ARSList) on
> behalf of Daniel
> Hill
> Sent: Wed 9/28/2005 9:15 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: somewhere ...
>
>
>
>
> I use SQL Server Data Transformation Services to pull data from remote
> sources into local database tables. The tables are then
> scanned against
> their corresponding Remedy forms to determine if the data needs to be
> updated. Each table has a RequestID column that is populated
> from a query
> against the Remedy form. If the RequestID column is NULL,
> then the record
> is exported to a new.csv file. If the RequestID is NOT
> NULL, then the
> record is exported to an update.csv file. There are then 2
> jobs that kick
> off arimportcmd. 1 job imports using a Generate New ID mapping for the
> new.csv file. The other job imports using an Update Existing
> Record mapping
> for the update.csv file.
>
> With this method I don't have to worry about the system being
> unavailable
> while the data refreshes. While the SQL Statements within the
> DTS Package
> can be intense, it ensures that the workload required by
> Remedy is reduced.
> I have this running on 6 feeds currently and it works like a charm.
>
> P.S. - This method was used to overcome the Maximum Filter
> Operations I
> queried the list about the other week. After increasing the
> Maximum Filters
> I was happy with server utilization. It did, however, take 17 hours to
> process 60,000 of 300,000 records, during which time the
> Escalation Thread
> was tied up. Now the process runs in about 45 minutes and the
> escalation
> thread is only tied up for a few milliseconds. Thanks for
> everyone's input
> on the Maximum Filters.
>
> - Daniel
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG]On Behalf Of Serouche Rahimpour
> Sent: Wednesday, September 28, 2005 11:37 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: somewhere ...
>
>
> thanks again.
> I have another issue of this kind which is the following:
> - I have to update everyday the user form with new data.
> - data can be of course updated but it can be the same
> - the output is in csv format
> - my user form has one index on emails
> The problem is that when I use the arimport to import the csv
> file into
> my form, it always ask to generate new entry-ids. Which I
> don't want to.
> So every day I delete the whole data in the form. I then
> import the data
> and that works fine.
> Is there another way of getting round into this?
> I mean this must be something to set... maybe in the form or an AL...
> Any idea?
>
>
> Serouche Rahimpour
> DCS Site Manager - Munich
>
> Phone +49(0) 89-3200-6673
> Fax +49(0) 89-3200-6898
> Mob +49(0)176-2946-7484
>
> http://www.dcs.ch
>
>
>
> McKenzie, James J C-E LCMC HQISEC/L3 wrote:
>
> >Serouche:
> >
> >Did you delete the data through the Remedy User Tool or
> through SQL code
> >applied directly to the database?
> >
> >If it is the latter, it is possible that the database is out
> of sync with
> >the values stored in the Remedy database tables.
> >
> >If you deleted entries in the T table, you MUST delete the
> >corresponding entries in the B and h
> >tables as well as any data in any extended data tables.
> >
> >James McKenzie
> >Remedy Engineer
> >C-E LCMC HQISEC, US Army
> >L-3 GSI
> >-----Original Message-----
> >From: Action Request System discussion list(ARSList)
> >[mailto:arslist@ARSLIST.ORG]On Behalf Of Serouche Rahimpour
> >Sent: Wednesday, September 28, 2005 5:11 AM
> >To: arslist@ARSLIST.ORG
> >Subject: somewhere ...
> >
> >
> >Hi listers,
> >
> >ARS 6.01
> >Sybase 12.5.3
> >Sun solaris 5.9
> >
> >I deleted data on the DB.
> >I try now to import data into my form with arimport tool.
> >No way. I get all the time " The value(s) for this entry violate a
> >unique index that has been defined for this form (ARERR 382)"
> >I can't get where these indexes are stored.
> >I though in some cache. So I restarted the server.
> >Nothing helps.
> >Will be anyone kind enough to give a help on that ?
> >Thank you.
> >
> >--
> >
> >Serouche Rahimpour
> >DCS Site Manager - Munich
> >
> >Phone +49(0) 89-3200-6673
> >Fax +49(0) 89-3200-6898
> >Mob +49(0)176-2946-7484
> >
> > http://www.dcs.ch
> >
> >
>
>
> >
> >UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> >(Support: mailto:support@arslist.org)
> >
> >
>
>
> >UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> >(Support: mailto:support@arslist.org)
> >
> >
> >
> >
>
>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>
>
>
> ===================================================================
> NOTICE - CONFIDENTIAL AND PRIVILEGED - This e-mail may contain
> privileged and confidential information and is intended only for the
> addressee named above. If you received this message in error,
> please immediately notify the sender by return e-mail and delete the
> original message; any distribution, copying or use of this e-mail
> by you is strictly prohibited and may be unlawful.
>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>
>
>
>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>
>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>
>
>
>
>
>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>
>
> This posting was submitted via the Web
> interface
>
>
>
> UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
> (Support: mailto:support@arslist.org)
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

my grandma used to say: " from birth to the grave, just learn, learn and
learn". What I try to do everyday of my life.
Thanks to you guys and also to the Remedy documentation.
Another concern is I am just wondering whether for my upgrade I could
just run sql queries on the database form one server to another, things
like "insert into DBDest.Txxx select from DBSource.Txxx"
I am wondering whether it would be enough? I mean I have tables with
same column on both databases.
Main differences are in the indexes.
Do you know if on Sybase my data stored in the tables is also affected
by the indexes?
I mean for example if my View Alpha is build on tables T123 and B123,
and if I synchronize at the database level my tables T123, B123 and H123
from one server to the other (keeping in mind that the database source
is Sybase 12.0 and database dest. is Sybase 12.5.3), is that enough to
have same data? Will be the integrity saved?
I am wondering whether you might have an answer.
That would be nice if you coud have an answer.
Thanks in advance.


Serouche Rahimpour
DCS Site Manager - Munich

Phone +49(0) 89-3200-6673
Fax +49(0) 89-3200-6898
Mob +49(0)176-2946-7484

http://www.dcs.ch



Doug Blair wrote:

>Alan, James et al,
>
>You might want to experiment with the -e option of arimportcmd.
>
>According to page 560-564 of the Advanced Guide for 6.3, -e will let you
>specify a field ID to be tested for duplicate ID's. Assuming that the
>case-matching issues have been resolved you could run arimportcmd -e 101
>(and some other arguments for mapping and file name) to test the login name
>field to be a duplicate entry instead of testing field 1, Request ID. When
>field 101 determines that the incoming data is a duplicate record (or not),
>then I assume that your mapping's behavior for updating the existing record
>or creating a new one would apply. The field you choose should be unique and
>ideally indexed (it has always bothered me that the User and group forms
>have no indexes by default).
>
>I haven't actually tried this yet, and there is minor historic precedent for
>documentation being out of step with the tool's behavior, but I think this
>should work.
>
>If I had to solve this problem I would favor use of a staging form because
>you can use workflow to clean up the data, format email addresses and so
>forth, and to avoid the potential task of recovering Remedy administrator
>accounts. If you import into the User form from (for example) a daily export
>CSV from the HR department, you'd also need some mechanism to periodically
>delete (or render useless) records that were not in the file. Presumably
>those would be employees no longer with the company.
>
>Doug Blair
>
>
>
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG] On Behalf Of McKenzie, James J
>>C-E LCMC HQISEC/L3
>>Sent: Wednesday, September 28, 2005 4:21 PM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>Susan:
>>
>>Simple answer is no, you cannot import based on a different
>>field than field
>>id 1, and I don't think this will change anytime soon as
>>field id 1 is the
>>only field that will be unique on each and every form.
>>
>>James McKenzie
>>Remedy Engineer
>>C-E LCMC HQISEC, US Army
>>L-3 GSI
>>
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Susan Palmer
>>Sent: Wednesday, September 28, 2005 11:26 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>**
>>No one asks where the new data is coming from.
>>Could the user form entry id be inserted into wherever that
>>data is coming
>>from?
>>Why does it have to be updated everynight?
>>Is it external customers as opposed to internal staff?
>>What are they logging into?
>>
>>Now I haven't looked this up but in v6+ can't you import
>>based on another
>>field other than entry id? I'm only on 5.1.2 and somehow
>>I've been looking
>>forward to that feature, although it might just have been a
>>dream ...lol
>>
>>Susan
>>
>>
>>
>>
>>On 9/28/05, McKenzie, James J C-E LCMC HQISEC/L3
>> wrote:
>>Rick:
>>
>>I would not try to do certain things with the User form, at least not
>>directly. The indirect approach appears to be the best
>>method for changing
>>data in this form. I know that the User form is 'just
>>another form', but
>>delete your adminstrators and see what you have to go through
>>to fix it.
>>
>>James McKenzie
>>Remedy Engineer
>>C-E LCMC HQISEC, US Army
>>L-3 GSI
>>
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Rick Cook
>>Sent: Wednesday, September 28, 2005 10:45 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>...and your point is...? There's nothing inherent in the
>>User form that
>>prohibits this action. If he's trying to re-import that
>>which he deleted,
>>he needs to:
>>
>>*
>> tell his import mechanism to disregard the entry ID
>>and just force
>>the records into existing slots that may or may not match, or
>>*
>> find a way to map the entry ID and update the record
>>appropriately,
>>or
>>*
>> reset the nextID and pretend it's an initial install.
>>
>>If there are existing records (which, from the error msg, it
>>appears that
>>there are), then it should be pretty easy to see what they
>>are and compare
>>them to his import file, perhaps merge the two, and go from there.
>>
>>Of course, the Unique Index error may also be a product of a
>>NULL value -
>>duplicate NULLs will spawn that error, too.
>>
>>
>>Rick
>>
>>
>>
>>From: Action Request System discussion list(ARSList) on
>>behalf of McKenzie,
>>James J C-E LCMC HQISEC/L3
>>Sent: Wed 9/28/2005 10:02 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>
>>
>>Rick:
>>
>>This is the USER form.
>>
>>James McKenzie
>>
>>
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Rick Cook
>>Sent: Wednesday, September 28, 2005 9:54 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>It sounds to me like that all he may need to do is reset the
>>nextID back to
>>1 for the import forms. It's easy to do, and the
>>instructions are in the
>>docs.
>>
>>
>>
>>
>>
>>
>>
>>Rick Cook * Senior Remedy Consultant * Denali Advanced
>>Integration * (253)
>>278-4112
>>
>>
>>
>>From: Action Request System discussion list(ARSList) on
>>behalf of Daniel
>>Hill
>>Sent: Wed 9/28/2005 9:15 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>
>>
>>I use SQL Server Data Transformation Services to pull data from remote
>>sources into local database tables. The tables are then
>>scanned against
>>their corresponding Remedy forms to determine if the data needs to be
>>updated. Each table has a RequestID column that is populated
>>from a query
>>against the Remedy form. If the RequestID column is NULL,
>>then the record
>>is exported to a new.csv file. If the RequestID is NOT
>>NULL, then the
>>record is exported to an update.csv file. There are then 2
>>jobs that kick
>>off arimportcmd. 1 job imports using a Generate New ID mapping for the
>>new.csv file. The other job imports using an Update Existing
>>Record mapping
>>for the update.csv file.
>>
>>With this method I don't have to worry about the system being
>>unavailable
>>while the data refreshes. While the SQL Statements within the
>>DTS Package
>>can be intense, it ensures that the workload required by
>>Remedy is reduced.
>>I have this running on 6 feeds currently and it works like a charm.
>>
>>P.S. - This method was used to overcome the Maximum Filter
>>Operations I
>>queried the list about the other week. After increasing the
>>Maximum Filters
>>I was happy with server utilization. It did, however, take 17 hours to
>>process 60,000 of 300,000 records, during which time the
>>Escalation Thread
>>was tied up. Now the process runs in about 45 minutes and the
>>escalation
>>thread is only tied up for a few milliseconds. Thanks for
>>everyone's input
>>on the Maximum Filters.
>>
>>- Daniel
>>
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Serouche Rahimpour
>>Sent: Wednesday, September 28, 2005 11:37 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>thanks again.
>>I have another issue of this kind which is the following:
>>- I have to update everyday the user form with new data.
>>- data can be of course updated but it can be the same
>>- the output is in csv format
>>- my user form has one index on emails
>>The problem is that when I use the arimport to import the csv
>>file into
>>my form, it always ask to generate new entry-ids. Which I
>>don't want to.
>>So every day I delete the whole data in the form. I then
>>import the data
>>and that works fine.
>>Is there another way of getting round into this?
>>I mean this must be something to set... maybe in the form or an AL...
>>Any idea?
>>
>>
>>Serouche Rahimpour
>>DCS Site Manager - Munich
>>
>>Phone +49(0) 89-3200-6673
>>Fax +49(0) 89-3200-6898
>>Mob +49(0)176-2946-7484
>>
>> http://www.dcs.ch
>>
>>
>>
>>McKenzie, James J C-E LCMC HQISEC/L3 wrote:
>>
>>
>>
>>>Serouche:
>>>
>>>Did you delete the data through the Remedy User Tool or
>>>
>>>
>>through SQL code
>>
>>
>>>applied directly to the database?
>>>
>>>If it is the latter, it is possible that the database is out
>>>
>>>
>>of sync with
>>
>>
>>>the values stored in the Remedy database tables.
>>>
>>>If you deleted entries in the T table, you MUST delete the
>>>corresponding entries in the B and h
>>>tables as well as any data in any extended data tables.
>>>
>>>James McKenzie
>>>Remedy Engineer
>>>C-E LCMC HQISEC, US Army
>>>L-3 GSI
>>>-----Original Message-----
>>>From: Action Request System discussion list(ARSList)
>>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Serouche Rahimpour
>>>Sent: Wednesday, September 28, 2005 5:11 AM
>>>To: arslist@ARSLIST.ORG
>>>Subject: somewhere ...
>>>
>>>
>>>Hi listers,
>>>
>>>ARS 6.01
>>>Sybase 12.5.3
>>>Sun solaris 5.9
>>>
>>>I deleted data on the DB.
>>>I try now to import data into my form with arimport tool.
>>>No way. I get all the time " The value(s) for this entry violate a
>>>unique index that has been defined for this form (ARERR 382)"
>>>I can't get where these indexes are stored.
>>>I though in some cache. So I restarted the server.
>>>Nothing helps.
>>>Will be anyone kind enough to give a help on that ?
>>>Thank you.
>>>
>>>--
>>>
>>>Serouche Rahimpour
>>>DCS Site Manager - Munich
>>>
>>>Phone +49(0) 89-3200-6673
>>>Fax +49(0) 89-3200-6898
>>>Mob +49(0)176-2946-7484
>>>
>>> http://www.dcs.ch
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>===================================================================
>>NOTICE - CONFIDENTIAL AND PRIVILEGED - This e-mail may contain
>>privileged and confidential information and is intended only for the
>>addressee named above. If you received this message in error,
>>please immediately notify the sender by return e-mail and delete the
>>original message; any distribution, copying or use of this e-mail
>>by you is strictly prohibited and may be unlawful.
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>This posting was submitted via the Web
>>interface
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Doug:

Sounds good to me. However, will it skip the requirement to have Field ID 1
for matching existing entries to be updates vice a new entry?

James McKenzie


-----Original Message-----
From: Action Request System discussion list(ARSList)
To: arslist@ARSLIST.ORG
Sent: 9/29/2005 6:23 AM
Subject: Re: somewhere ...

Alan, James et al,

You might want to experiment with the -e option of arimportcmd.

According to page 560-564 of the Advanced Guide for 6.3, -e will let you
specify a field ID to be tested for duplicate ID's. Assuming that the
case-matching issues have been resolved you could run arimportcmd -e 101
(and some other arguments for mapping and file name) to test the login
name
field to be a duplicate entry instead of testing field 1, Request ID.
When
field 101 determines that the incoming data is a duplicate record (or
not),
then I assume that your mapping's behavior for updating the existing
record
or creating a new one would apply. The field you choose should be unique
and
ideally indexed (it has always bothered me that the User and group forms
have no indexes by default).

I haven't actually tried this yet, and there is minor historic precedent
for
documentation being out of step with the tool's behavior, but I think
this
should work.

If I had to solve this problem I would favor use of a staging form
because
you can use workflow to clean up the data, format email addresses and so
forth, and to avoid the potential task of recovering Remedy
administrator
accounts. If you import into the User form from (for example) a daily
export
CSV from the HR department, you'd also need some mechanism to
periodically
delete (or render useless) records that were not in the file. Presumably
those would be employees no longer with the company.

Doug Blair


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Serouche:

I would not rely on using database tables because they can and do vary from
server to server. I would use the functionality of the Remedy User tool to
do the export from my production server and then use the functionality of
the Remedy Import program to pull in data to the dev. server keeping in mind
the 2000 record limit if my dev server was not totally licensed.

James McKenzie


-----Original Message-----
From: Action Request System discussion list(ARSList)
To: arslist@ARSLIST.ORG
Sent: 9/29/2005 7:54 AM
Subject: Re: somewhere ...

my grandma used to say: " from birth to the grave, just learn, learn and
learn". What I try to do everyday of my life.
Thanks to you guys and also to the Remedy documentation.
Another concern is I am just wondering whether for my upgrade I could
just run sql queries on the database form one server to another, things
like "insert into DBDest.Txxx select from DBSource.Txxx"
I am wondering whether it would be enough? I mean I have tables with
same column on both databases.
Main differences are in the indexes.
Do you know if on Sybase my data stored in the tables is also affected
by the indexes?
I mean for example if my View Alpha is build on tables T123 and B123,
and if I synchronize at the database level my tables T123, B123 and H123
from one server to the other (keeping in mind that the database source
is Sybase 12.0 and database dest. is Sybase 12.5.3), is that enough to
have same data? Will be the integrity saved?
I am wondering whether you might have an answer.
That would be nice if you coud have an answer.
Thanks in advance.


Serouche Rahimpour
DCS Site Manager - Munich

Phone +49(0) 89-3200-6673
Fax +49(0) 89-3200-6898
Mob +49(0)176-2946-7484

http://www.dcs.ch



Doug Blair wrote:

>Alan, James et al,
>
>You might want to experiment with the -e option of arimportcmd.
>
>According to page 560-564 of the Advanced Guide for 6.3, -e will let
you
>specify a field ID to be tested for duplicate ID's. Assuming that the
>case-matching issues have been resolved you could run arimportcmd -e
101
>(and some other arguments for mapping and file name) to test the login
name
>field to be a duplicate entry instead of testing field 1, Request ID.
When
>field 101 determines that the incoming data is a duplicate record (or
not),
>then I assume that your mapping's behavior for updating the existing
record
>or creating a new one would apply. The field you choose should be
unique and
>ideally indexed (it has always bothered me that the User and group
forms
>have no indexes by default).
>
>I haven't actually tried this yet, and there is minor historic
precedent for
>documentation being out of step with the tool's behavior, but I think
this
>should work.
>
>If I had to solve this problem I would favor use of a staging form
because
>you can use workflow to clean up the data, format email addresses and
so
>forth, and to avoid the potential task of recovering Remedy
administrator
>accounts. If you import into the User form from (for example) a daily
export
>CSV from the HR department, you'd also need some mechanism to
periodically
>delete (or render useless) records that were not in the file.
Presumably
>those would be employees no longer with the company.
>
>Doug Blair
>
>
>
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG] On Behalf Of McKenzie, James J
>>C-E LCMC HQISEC/L3
>>Sent: Wednesday, September 28, 2005 4:21 PM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>Susan:
>>
>>Simple answer is no, you cannot import based on a different
>>field than field
>>id 1, and I don't think this will change anytime soon as
>>field id 1 is the
>>only field that will be unique on each and every form.
>>
>>James McKenzie
>>Remedy Engineer
>>C-E LCMC HQISEC, US Army
>>L-3 GSI
>>
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Susan Palmer
>>Sent: Wednesday, September 28, 2005 11:26 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>**
>>No one asks where the new data is coming from.
>>Could the user form entry id be inserted into wherever that
>>data is coming
>>from?
>>Why does it have to be updated everynight?
>>Is it external customers as opposed to internal staff?
>>What are they logging into?
>>
>>Now I haven't looked this up but in v6+ can't you import
>>based on another
>>field other than entry id? I'm only on 5.1.2 and somehow
>>I've been looking
>>forward to that feature, although it might just have been a
>>dream ...lol
>>
>>Susan
>>
>>
>>
>>
>>On 9/28/05, McKenzie, James J C-E LCMC HQISEC/L3
>> wrote:
>>Rick:
>>
>>I would not try to do certain things with the User form, at least not
>>directly. The indirect approach appears to be the best
>>method for changing
>>data in this form. I know that the User form is 'just
>>another form', but
>>delete your adminstrators and see what you have to go through
>>to fix it.
>>
>>James McKenzie
>>Remedy Engineer
>>C-E LCMC HQISEC, US Army
>>L-3 GSI
>>
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Rick Cook
>>Sent: Wednesday, September 28, 2005 10:45 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>...and your point is...? There's nothing inherent in the
>>User form that
>>prohibits this action. If he's trying to re-import that
>>which he deleted,
>>he needs to:
>>
>>*
>> tell his import mechanism to disregard the entry ID
>>and just force
>>the records into existing slots that may or may not match, or
>>*
>> find a way to map the entry ID and update the record
>>appropriately,
>>or
>>*
>> reset the nextID and pretend it's an initial install.
>>
>>If there are existing records (which, from the error msg, it
>>appears that
>>there are), then it should be pretty easy to see what they
>>are and compare
>>them to his import file, perhaps merge the two, and go from there.
>>
>>Of course, the Unique Index error may also be a product of a
>>NULL value -
>>duplicate NULLs will spawn that error, too.
>>
>>
>>Rick
>>
>>
>>
>>From: Action Request System discussion list(ARSList) on
>>behalf of McKenzie,
>>James J C-E LCMC HQISEC/L3
>>Sent: Wed 9/28/2005 10:02 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>
>>
>>Rick:
>>
>>This is the USER form.
>>
>>James McKenzie
>>
>>
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Rick Cook
>>Sent: Wednesday, September 28, 2005 9:54 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>It sounds to me like that all he may need to do is reset the
>>nextID back to
>>1 for the import forms. It's easy to do, and the
>>instructions are in the
>>docs.
>>
>>
>>
>>
>>
>>
>>
>>Rick Cook * Senior Remedy Consultant * Denali Advanced
>>Integration * (253)
>>278-4112
>>
>>
>>
>>From: Action Request System discussion list(ARSList) on
>>behalf of Daniel
>>Hill
>>Sent: Wed 9/28/2005 9:15 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>
>>
>>I use SQL Server Data Transformation Services to pull data from remote
>>sources into local database tables. The tables are then
>>scanned against
>>their corresponding Remedy forms to determine if the data needs to be
>>updated. Each table has a RequestID column that is populated
>>from a query
>>against the Remedy form. If the RequestID column is NULL,
>>then the record
>>is exported to a new.csv file. If the RequestID is NOT
>>NULL, then the
>>record is exported to an update.csv file. There are then 2
>>jobs that kick
>>off arimportcmd. 1 job imports using a Generate New ID mapping for the
>>new.csv file. The other job imports using an Update Existing
>>Record mapping
>>for the update.csv file.
>>
>>With this method I don't have to worry about the system being
>>unavailable
>>while the data refreshes. While the SQL Statements within the
>>DTS Package
>>can be intense, it ensures that the workload required by
>>Remedy is reduced.
>>I have this running on 6 feeds currently and it works like a charm.
>>
>>P.S. - This method was used to overcome the Maximum Filter
>>Operations I
>>queried the list about the other week. After increasing the
>>Maximum Filters
>>I was happy with server utilization. It did, however, take 17 hours to
>>process 60,000 of 300,000 records, during which time the
>>Escalation Thread
>>was tied up. Now the process runs in about 45 minutes and the
>>escalation
>>thread is only tied up for a few milliseconds. Thanks for
>>everyone's input
>>on the Maximum Filters.
>>
>>- Daniel
>>
>>-----Original Message-----
>>From: Action Request System discussion list(ARSList)
>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Serouche Rahimpour
>>Sent: Wednesday, September 28, 2005 11:37 AM
>>To: arslist@ARSLIST.ORG
>>Subject: Re: somewhere ...
>>
>>
>>thanks again.
>>I have another issue of this kind which is the following:
>>- I have to update everyday the user form with new data.
>>- data can be of course updated but it can be the same
>>- the output is in csv format
>>- my user form has one index on emails
>>The problem is that when I use the arimport to import the csv
>>file into
>>my form, it always ask to generate new entry-ids. Which I
>>don't want to.
>>So every day I delete the whole data in the form. I then
>>import the data
>>and that works fine.
>>Is there another way of getting round into this?
>>I mean this must be something to set... maybe in the form or an AL...
>>Any idea?
>>
>>
>>Serouche Rahimpour
>>DCS Site Manager - Munich
>>
>>Phone +49(0) 89-3200-6673
>>Fax +49(0) 89-3200-6898
>>Mob +49(0)176-2946-7484
>>
>> http://www.dcs.ch
>>
>>
>>
>>McKenzie, James J C-E LCMC HQISEC/L3 wrote:
>>
>>
>>
>>>Serouche:
>>>
>>>Did you delete the data through the Remedy User Tool or
>>>
>>>
>>through SQL code
>>
>>
>>>applied directly to the database?
>>>
>>>If it is the latter, it is possible that the database is out
>>>
>>>
>>of sync with
>>
>>
>>>the values stored in the Remedy database tables.
>>>
>>>If you deleted entries in the T table, you MUST delete the
>>>corresponding entries in the B and h
>>>tables as well as any data in any extended data tables.
>>>
>>>James McKenzie
>>>Remedy Engineer
>>>C-E LCMC HQISEC, US Army
>>>L-3 GSI
>>>-----Original Message-----
>>>From: Action Request System discussion list(ARSList)
>>>[mailto:arslist@ARSLIST.ORG]On Behalf Of Serouche Rahimpour
>>>Sent: Wednesday, September 28, 2005 5:11 AM
>>>To: arslist@ARSLIST.ORG
>>>Subject: somewhere ...
>>>
>>>
>>>Hi listers,
>>>
>>>ARS 6.01
>>>Sybase 12.5.3
>>>Sun solaris 5.9
>>>
>>>I deleted data on the DB.
>>>I try now to import data into my form with arimport tool.
>>>No way. I get all the time " The value(s) for this entry violate a
>>>unique index that has been defined for this form (ARERR 382)"
>>>I can't get where these indexes are stored.
>>>I though in some cache. So I restarted the server.
>>>Nothing helps.
>>>Will be anyone kind enough to give a help on that ?
>>>Thank you.
>>>
>>>--
>>>
>>>Serouche Rahimpour
>>>DCS Site Manager - Munich
>>>
>>>Phone +49(0) 89-3200-6673
>>>Fax +49(0) 89-3200-6898
>>>Mob +49(0)176-2946-7484
>>>
>>> http://www.dcs.ch
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>===================================================================
>>NOTICE - CONFIDENTIAL AND PRIVILEGED - This e-mail may contain
>>privileged and confidential information and is intended only for the
>>addressee named above. If you received this message in error,
>>please immediately notify the sender by return e-mail and delete the
>>original message; any distribution, copying or use of this e-mail
>>by you is strictly prohibited and may be unlawful.
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>This posting was submitted via the Web
>>interface
>>
>>
>>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>
>



UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

James,

I'm not sure I fully understand that requirement, as the only (easy) way
you'll be able to do that will be to import a new record and then delete the
corresponding old one with workflow. Within the Remedy data model column 1
is the primary and unique key in a number of other tables - status history,
attachments, diaries and so forth. The Request ID field (a/k/a Entry-Id,
Case ID+, etc) is the identifier for most of the fields you see in a form.
It is also, however, the key for extra tables in the database that hold the
values for the status history, for each diary field or large character
field, and a few others. If you somehow update the request ID for the form
you'll have to update those other corresponding database tables too, or you
will lose linkage to the times the records changed status.

This is technically not impossible to do. You would need use SQL to update
C1 in Hxxx set C1 = 'ABC000newnumber' where C1 = 'ABC000oldnumber', where
xxx is the numerical ID of the User form as recorded in the arschema table,
and you need to make corresponding updates to the Bxxx tables and any others
I've missed. Have a look at the back database sections of the Advanced
manual to get an idea of how your database is organized, and you'll see that
modifying the primary key is not a task to be undertaken lightly. If you're
using Remedy's OOB apps the Request ID (or at least the existence of one) is
used to lookup some other information on the fly, so there are probably
other things to update too.

However, this method is so kludged that this is the point where I would have
a serious chat with the client to find out what they're trying to accomplish
with this requirement. There are lots of other ways to identify changes to a
record, last time updated, who changed what from what to what when, and to
make this information available to external sources, that I cannot imagine
why they want that particular field to change. You could, in a pinch, just
add a counter field to the User form and increment that with each update,
append it to the real request ID in a plain character field and publish that
as your unique identifier.

So, it can be done. You just don't want to do it. You really don't :-)

Doug

> -----Original Message-----
> From: McKenzie, James J C-E LCMC HQISEC/L3
> [mailto:James.McKenzie@HQISEC.ARMY.MIL]
> Sent: Thursday, September 29, 2005 11:16 AM
> To: 'Doug Blair '; 'Action Request System discussion list(ARSList) '
> Subject: RE: somewhere ...
>
> Doug:
>
> Sounds good to me. However, will it skip the requirement to
> have Field ID 1
> for matching existing entries to be updates vice a new entry?
>
> James McKenzie
>
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> To: arslist@ARSLIST.ORG
> Sent: 9/29/2005 6:23 AM
> Subject: Re: somewhere ...
>
> Alan, James et al,
>
> You might want to experiment with the -e option of arimportcmd.
>
> According to page 560-564 of the Advanced Guide for 6.3, -e
> will let you
> specify a field ID to be tested for duplicate ID's. Assuming that the
> case-matching issues have been resolved you could run
> arimportcmd -e 101
> (and some other arguments for mapping and file name) to test the login
> name
> field to be a duplicate entry instead of testing field 1, Request ID.
> When
> field 101 determines that the incoming data is a duplicate record (or
> not),
> then I assume that your mapping's behavior for updating the existing
> record
> or creating a new one would apply. The field you choose
> should be unique
> and
> ideally indexed (it has always bothered me that the User and
> group forms
> have no indexes by default).
>
> I haven't actually tried this yet, and there is minor
> historic precedent
> for
> documentation being out of step with the tool's behavior, but I think
> this
> should work.
>
> If I had to solve this problem I would favor use of a staging form
> because
> you can use workflow to clean up the data, format email
> addresses and so
> forth, and to avoid the potential task of recovering Remedy
> administrator
> accounts. If you import into the User form from (for example) a daily
> export
> CSV from the HR department, you'd also need some mechanism to
> periodically
> delete (or render useless) records that were not in the file.
> Presumably
> those would be employees no longer with the company.
>
> Doug Blair
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Doug:

I'm not the OP, but rather stating an opinion. What the change does is
match the new field, which must be required and unique (like field id 1 is)
to the presented data. Internally, the AR Import tool retrieves the value
of field id 1 which matches the entry and uses that to update the record.
If the value does not exist, then a new record is created. If you select a
field that is not required and unique, the AR Import tool advises that the
field cannot be used. This eliminates the need to use field id 1 for import
purposes.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC, US Army
L-3 GSI

-----Original Message-----
From: Doug Blair [mailto:doug@blairing.com]
Sent: Sunday, October 02, 2005 5:40 AM
To: 'McKenzie, James J C-E LCMC HQISEC/L3'; arslist@ARSLIST.ORG
Subject: RE: somewhere ...


James,

I'm not sure I fully understand that requirement, as the only (easy) way
you'll be able to do that will be to import a new record and then delete the
corresponding old one with workflow. Within the Remedy data model column 1
is the primary and unique key in a number of other tables - status history,
attachments, diaries and so forth. The Request ID field (a/k/a Entry-Id,
Case ID+, etc) is the identifier for most of the fields you see in a form.
It is also, however, the key for extra tables in the database that hold the
values for the status history, for each diary field or large character
field, and a few others. If you somehow update the request ID for the form
you'll have to update those other corresponding database tables too, or you
will lose linkage to the times the records changed status.

This is technically not impossible to do. You would need use SQL to update
C1 in Hxxx set C1 = 'ABC000newnumber' where C1 = 'ABC000oldnumber', where
xxx is the numerical ID of the User form as recorded in the arschema table,
and you need to make corresponding updates to the Bxxx tables and any others
I've missed. Have a look at the back database sections of the Advanced
manual to get an idea of how your database is organized, and you'll see that
modifying the primary key is not a task to be undertaken lightly. If you're
using Remedy's OOB apps the Request ID (or at least the existence of one) is
used to lookup some other information on the fly, so there are probably
other things to update too.

However, this method is so kludged that this is the point where I would have
a serious chat with the client to find out what they're trying to accomplish
with this requirement. There are lots of other ways to identify changes to a
record, last time updated, who changed what from what to what when, and to
make this information available to external sources, that I cannot imagine
why they want that particular field to change. You could, in a pinch, just
add a counter field to the User form and increment that with each update,
append it to the real request ID in a plain character field and publish that
as your unique identifier.

So, it can be done. You just don't want to do it. You really don't :-)

Doug

> -----Original Message-----
> From: McKenzie, James J C-E LCMC HQISEC/L3
> [mailto:James.McKenzie@HQISEC.ARMY.MIL]
> Sent: Thursday, September 29, 2005 11:16 AM
> To: 'Doug Blair '; 'Action Request System discussion list(ARSList) '
> Subject: RE: somewhere ...
>
> Doug:
>
> Sounds good to me. However, will it skip the requirement to
> have Field ID 1
> for matching existing entries to be updates vice a new entry?
>
> James McKenzie
>
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> To: arslist@ARSLIST.ORG
> Sent: 9/29/2005 6:23 AM
> Subject: Re: somewhere ...
>
> Alan, James et al,
>
> You might want to experiment with the -e option of arimportcmd.
>
> According to page 560-564 of the Advanced Guide for 6.3, -e
> will let you
> specify a field ID to be tested for duplicate ID's. Assuming that the
> case-matching issues have been resolved you could run
> arimportcmd -e 101
> (and some other arguments for mapping and file name) to test the login
> name
> field to be a duplicate entry instead of testing field 1, Request ID.
> When
> field 101 determines that the incoming data is a duplicate record (or
> not),
> then I assume that your mapping's behavior for updating the existing
> record
> or creating a new one would apply. The field you choose
> should be unique
> and
> ideally indexed (it has always bothered me that the User and
> group forms
> have no indexes by default).
>
> I haven't actually tried this yet, and there is minor
> historic precedent
> for
> documentation being out of step with the tool's behavior, but I think
> this
> should work.
>
> If I had to solve this problem I would favor use of a staging form
> because
> you can use workflow to clean up the data, format email
> addresses and so
> forth, and to avoid the potential task of recovering Remedy
> administrator
> accounts. If you import into the User form from (for example) a daily
> export
> CSV from the HR department, you'd also need some mechanism to
> periodically
> delete (or render useless) records that were not in the file.
> Presumably
> those would be employees no longer with the company.
>
> Doug Blair
>
>


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)