You can do this in SQL if you're brave. It is doable and not that bad. Always backup first! Make sure ARS is down.
Also, if you have SQL procedures, why couldn't those procedures look up the IDs from the table names? (inner select). Or better still, use the views that Remedy automatically created since at least version 6? Yes, the horses have left and it's a little late to close the barn doors. However, I would argue strongly for a change to those responsible for the SQL procs to use the views now. It's more readable and more maintainable in any event. If you are importing, import just the table. Eliminate the views from the .def. Else there will be a bunch of views etc to be changed. Check out the database reference guide for some of the details. There are many tables with the field "SchemaId". Mostly they describe fields. Then change the IDs manually (ugly, dangerous) in all the appropriate tables - several field definition tables based on field types! Check the results with the admin tool / dev studio or other ways of dumping table fields if you have them. Then reimport the table with the views. The ID will not have changed. Now import the workflow. If you have a bunch of tables I would script the process. That's how I would approach it. I wouldn't use archgid unless I wrote it or had it fully tested. Others have had some problems with it, it would seem. I have no experience with it. I do these types of (thankfully rare) things manually. Remember to back up before doing direct SQL on the ARS "hidden" data definition tables. Remember also that ARS should be down. Good luck. Cheers Ben -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jarl Grøneng Sent: July-28-10 20:58 To: [email protected] Subject: Re: ARS v7.5 - importing forms changed Table ID 1) Yes. The related B and T tables get also renamed. The tableid can be used in direct SQL, but a good documented system should pinpoint them. We did encounter some fault using archigid when changing fieldids on 7.5 server. Set Field action from other froms did not always get updated, same with menues. -- J 2010/7/28 Susan Palmer <[email protected]>: > ** > I had 400+ forms to import and what it did was give them sequential > numbers. Usually I've just copied the database over but with the old > vs new version that was not going to work. I can't say I gave the > table ID much thought ahead of time but will certainly remember going forward. > > So all the table IDs I want to use are already used. But the good > news is there are really only about 10 tables I have to manipulate. > > I did a quick survey of the other application owners and there's a > mixed bag with several using Table IDs. > > My choices appear to be: > > 1. Use archgid to change the wrong table to a new number and then > change the right table to the number it should be. But I cannot find > archgid on the server, where to get it in the KB. There was a post > about using the windows_zg_ia_sf.jar file which I have but I have to > get the server guys to put it on the unix server. And then I guess > magically I'll find archgid there. Does archgid change all the related table IDs, T, H, B etc? > > 2. I think it was Fred's idea to basically delete the wrong forms in > question. Reset set the Table ID and then import them individually > after each required Table ID reset. I assume that I reset the Table > ID in the database. Rather than play around maybe someone could > provide the correct sql statement. I'd have to reimport the workflow > objects etc also and the 11hrs worth of data which of course is on one > of the forms will need to be recopied over. But I figure I only have > in the neighborhood of 200 hrs of data to move so that's not the worst of it. > > #1 sounds good and I have some garbage forms to test it on. Any other > last thoughts? > > Is the table ID buried in anything else? I have only seen the schema > name in workflow and checked but didn't see anything obvious that > might be a cross reference. > > I really do appreciate the input. These are the kinds of things you > want to talk over. Ok, so I do talk to myself but sometimes I'm not > as creative as you ! > > Thanks, > Susan > > On Wed, Jul 28, 2010 at 12:10 PM, Guillaume Rheault > <[email protected]> > wrote: >> >> ** >> LJ, >> >> I don't disagree...I am just saying that using that function of >> archig may still pose a risk, since it is probably not used often, >> even though it seems a small risk. >> But if I ever had to change the table ID, I would use the archig >> utility, I would not do the manual updates at all..... >> >> Susan: >> >> Yet another option is to create a database view with the schemaid you >> would like,provided of course there is no tabeld with that ID. So for >> instance let's sat you have table T500 and you would like T300, check >> whether there is a table T300, and if not, create a daatbase view >> caleld >> T300 that referes to table T500. This way, you don't need to change >> anything on the Remedy structures. >> >> Guillaume >> >> ________________________________ >> On Wed, Jul 28, 2010 at 11:15 AM, LJ LongWing <[email protected]> >> wrote: >> >> ** That is always a chance but I would trust archgid more than I >> would trust me doing it manually .and I agree with your assessment, >> TID should NEVER be used in direct SQL .I ALWAYS recommend using View >> names instead of table ids .still fragile, but less so that table id >> J _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
