I am assuming that you will have the same issue in future migrations/upgrade and I would rather spend time analyzing/ tweaking/ optimizing workflow by removing hardcoded values, use Views in Direct SQL etc.. which may result in better system performance.
Just an opinion. Thanks Mahesh On Wed, Jul 28, 2010 at 1:30 PM, Susan Palmer <[email protected]> wrote: > ** > 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"
