Re: Transferring in-house 6.3 code to a 7.6.04 server
This last sentence is not 100% true. I agree with you with the
recommendation of pointing to views at direct SQL actions instead of T
tables. But, although it is very unlikely, it is not guaranteed that the
view name of the form won't change when migrating. If two form names
collide with the view name one of them will have the scheme number in the
name.
El miércoles 11 de abril de 2012, Joe Martin D'Souza escribió:
**
A very useful tip:
Many of you may know this.. If you MUST write a Direct SQL, you NEVER
should write SQL directly to T tables.. Instead write them against the view
name.. for eg if you wanted to write one for the HPD:HelpDesk form whose
table is lets say T654 do not write it to T654.. Describe HPD_HelpDesk and
write it to that.. Then the upgrade would be seamless as the view name
never changes..
You may want to consider a project where if you have Direct SQL’s to the T
tables, convert them to address the view names..
Joe
*From:* Susan Palmer javascript:_e({}, 'cvml',
'suzanpal...@gmail.com');
*Sent:* Tuesday, April 10, 2012 7:57 PM
*Newsgroups:* public.remedy.arsystem.general
*To:* arslist@ARSLIST.ORG javascript:_e({}, 'cvml',
'arslist@ARSLIST.ORG');
*Subject:* Re: Transferring in-house 6.3 code to a 7.6.04 server
** We did an upgrade (mis-nomer) last year. After 3 months of trying to
upgrade we ended up just creating new servers and export/importing
objects. The biggest gotcha we ran into was when you import forms to the
new database it changes the form ID (T236 became T450). Any sql statements
included in workflow needed to be updated and external programs needed to
be updated.
There were other things and if you take the time to search archives I
described them pretty extensively.
Good luck!!
Susan
On Tue, Apr 10, 2012 at 11:05 AM, David M. Clark
david.m.cl...@tn.govjavascript:_e({}, 'cvml', 'david.m.cl...@tn.gov');
wrote:
**
Folks,
I am finally in the process of upgrading our 6.03.00 patch 017
implementation to the latest offered. By “upgrade” I mean a transfer
between old and new servers, not on the same server. The revs are
apparently too far apart to use Migrator to transfer code between, so I
will be using a 7.1 server as an intermediate transfer point. Migrator 7.1
from the 6.3 box to the 7.1 box, then the latest Migrator from the 7.1 box
to the 7.6.04 box. I’ll also be using Export/Import tools as needed. Note
that no BMC Remedy applications are involved here, though I will be loading
ITSM later. My concern now is only with in-house developed code created
under or compatible with version 6.3. Solaris and Oracle on both sides.*
***
Anyone ever done this or have any suggestions as to problems that I may
encounter?
Thanks,
-David
_attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_
--
Jose M. Huerta
Project Manager**
Movil: 661 665 088
Telf.: 971 75 03 24
Fax: 971 75 07 94
http://www.sm2baleares.es/
SM2 Baleares S.A.
C/Rita Levi
Edificio SM2 Parc Bit
07121 Palma de Mallorca
http://es-es.facebook.com/pages/SM2-Baleares/158608627954
http://twitter.com/#!/SM2Baleares
http://www.linkedin.com/company/sm2-baleares
La información contenida en este mensaje de correo electrónico es
confidencial. La misma, es enviada con la intención de que únicamente sea
leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje
por otras personas no está autorizado, por lo que en tal caso, le rogamos
que nos lo comunique por la misma vía, se abstenga de realizar copias del
mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de
inmediato.
P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es
necesario.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
image004.jpgimage003.jpgimage001.jpgimage002.jpg
Re: Transferring in-house 6.3 code to a 7.6.04 server
Hi, In addition to RRR|Chive, you might benefit from using RRR|DefHideExpandBox that will help you fix the layout of your forms after the upgrade, as fields 2, 4 and 5 will get an expand box appended to them as a result of a field length increase: https://www.rrr.se/cgi/tools/main#rrrDefHideExpandBox Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Ditto to what Joe said. We moved from 7.1 p7 to 7.6.04 SP2. We simply just created def files of all of our custom forms and then used RRRCHIVE to move the data. Something you may want to think about? Then I don't think you would need to use the interim 7.1 server? Up to you. We had about 517 forms to move (plus all the workflow). It really wasn't that bad Thanks! Lisa From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Tuesday, April 10, 2012 12:25 PM To: arslist@ARSLIST.ORG Subject: Re: Transferring in-house 6.3 code to a 7.6.04 server ** If you do not have any OTB applications, I do not think you got too much to worry about. Have you customized any of the core forms? Core workflow? By that I mean forms like the User, Group, Email Engine forms, etc.. If your answer to this is no, you can go your merry way as you might have in previous versions.. If you have customized these core forms and workflow, you might want to check with BMC if they have a hash file for just the core components, so that you can create the overlay layer for those customizations. And then go your merry way with what you want to do with your in house stuff.. I really do not see much you need to put on your watch list except for integrations etc you might have done to third party tools or applications that may face the possibilities of a breakdown if they are not compatible with the new ARS application server version. Joe From: David M. Clarkmailto:david.m.cl...@tn.gov Sent: Tuesday, April 10, 2012 12:05 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Transferring in-house 6.3 code to a 7.6.04 server ** Folks, I am finally in the process of upgrading our 6.03.00 patch 017 implementation to the latest offered. By upgrade I mean a transfer between old and new servers, not on the same server. The revs are apparently too far apart to use Migrator to transfer code between, so I will be using a 7.1 server as an intermediate transfer point. Migrator 7.1 from the 6.3 box to the 7.1 box, then the latest Migrator from the 7.1 box to the 7.6.04 box. I'll also be using Export/Import tools as needed. Note that no BMC Remedy applications are involved here, though I will be loading ITSM later. My concern now is only with in-house developed code created under or compatible with version 6.3. Solaris and Oracle on both sides. Anyone ever done this or have any suggestions as to problems that I may encounter? Thanks, -David _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Transferring in-house 6.3 code to a 7.6.04 server
Instead of hardcoding, you can retrieve the viewname from ARSchema table during run time by adding a set fields action. Thanks Mahesh On Wed, Apr 11, 2012 at 2:25 AM, Jose Huerta jose.hue...@sm2baleares.eswrote: ** This last sentence is not 100% true. I agree with you with the recommendation of pointing to views at direct SQL actions instead of T tables. But, although it is very unlikely, it is not guaranteed that the view name of the form won't change when migrating. If two form names collide with the view name one of them will have the scheme number in the name. El miércoles 11 de abril de 2012, Joe Martin D'Souza escribió: ** A very useful tip: Many of you may know this.. If you MUST write a Direct SQL, you NEVER should write SQL directly to T tables.. Instead write them against the view name.. for eg if you wanted to write one for the HPD:HelpDesk form whose table is lets say T654 do not write it to T654.. Describe HPD_HelpDesk and write it to that.. Then the upgrade would be seamless as the view name never changes.. You may want to consider a project where if you have Direct SQL’s to the T tables, convert them to address the view names.. Joe *From:* Susan Palmer *Sent:* Tuesday, April 10, 2012 7:57 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Transferring in-house 6.3 code to a 7.6.04 server ** We did an upgrade (mis-nomer) last year. After 3 months of trying to upgrade we ended up just creating new servers and export/importing objects. The biggest gotcha we ran into was when you import forms to the new database it changes the form ID (T236 became T450). Any sql statements included in workflow needed to be updated and external programs needed to be updated. There were other things and if you take the time to search archives I described them pretty extensively. Good luck!! Susan On Tue, Apr 10, 2012 at 11:05 AM, David M. Clark david.m.cl...@tn.govwrote: ** Folks, I am finally in the process of upgrading our 6.03.00 patch 017 implementation to the latest offered. By “upgrade” I mean a transfer between old and new servers, not on the same server. The revs are apparently too far apart to use Migrator to transfer code between, so I will be using a 7.1 server as an intermediate transfer point. Migrator 7.1 from the 6.3 box to the 7.1 box, then the latest Migrator from the 7.1 box to the 7.6.04 box. I’ll also be using Export/Import tools as needed. Note that no BMC Remedy applications are involved here, though I will be loading ITSM later. My concern now is only with in-house developed code created under or compatible with version 6.3. Solaris and Oracle on both sides. Anyone ever done this or have any suggestions as to problems that I may encounter? Thanks, -David _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ -- Jose M. Huerta Project Manager** Movil: 661 665 088 Telf.: 971 75 03 24 Fax: 971 75 07 94 http://www.sm2baleares.es/ SM2 Baleares S.A. C/Rita Levi Edificio SM2 Parc Bit 07121 Palma de Mallorca http://es-es.facebook.com/pages/SM2-Baleares/158608627954 http://twitter.com/#!/SM2Baleares http://www.linkedin.com/company/sm2-baleares La información contenida en este mensaje de correo electrónico es confidencial. La misma, es enviada con la intención de que únicamente sea leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje por otras personas no está autorizado, por lo que en tal caso, le rogamos que nos lo comunique por la misma vía, se abstenga de realizar copias del mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de inmediato. P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es necesario. _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Transferring in-house 6.3 code to a 7.6.04 server
Folks, I am finally in the process of upgrading our 6.03.00 patch 017 implementation to the latest offered. By upgrade I mean a transfer between old and new servers, not on the same server. The revs are apparently too far apart to use Migrator to transfer code between, so I will be using a 7.1 server as an intermediate transfer point. Migrator 7.1 from the 6.3 box to the 7.1 box, then the latest Migrator from the 7.1 box to the 7.6.04 box. I'll also be using Export/Import tools as needed. Note that no BMC Remedy applications are involved here, though I will be loading ITSM later. My concern now is only with in-house developed code created under or compatible with version 6.3. Solaris and Oracle on both sides. Anyone ever done this or have any suggestions as to problems that I may encounter? Thanks, -David ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Transferring in-house 6.3 code to a 7.6.04 server
If you do not have any OTB applications, I do not think you got too much to worry about. Have you customized any of the core forms? Core workflow? By that I mean forms like the User, Group, Email Engine forms, etc.. If your answer to this is no, you can go your merry way as you might have in previous versions.. If you have customized these core forms and workflow, you might want to check with BMC if they have a hash file for just the core components, so that you can create the overlay layer for those customizations. And then go your merry way with what you want to do with your in house stuff.. I really do not see much you need to put on your watch list except for integrations etc you might have done to third party tools or applications that may face the possibilities of a breakdown if they are not compatible with the new ARS application server version. Joe From: David M. Clark Sent: Tuesday, April 10, 2012 12:05 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Transferring in-house 6.3 code to a 7.6.04 server ** Folks, I am finally in the process of upgrading our 6.03.00 patch 017 implementation to the latest offered. By “upgrade” I mean a transfer between old and new servers, not on the same server. The revs are apparently too far apart to use Migrator to transfer code between, so I will be using a 7.1 server as an intermediate transfer point. Migrator 7.1 from the 6.3 box to the 7.1 box, then the latest Migrator from the 7.1 box to the 7.6.04 box. I’ll also be using Export/Import tools as needed. Note that no BMC Remedy applications are involved here, though I will be loading ITSM later. My concern now is only with in-house developed code created under or compatible with version 6.3. Solaris and Oracle on both sides. Anyone ever done this or have any suggestions as to problems that I may encounter? Thanks, -David ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Transferring in-house 6.3 code to a 7.6.04 server
Ditto to what Joe said. We moved from 7.1 p7 to 7.6.04 SP2. We simply just created def files of all of our custom forms and then used RRRCHIVE to move the data. Something you may want to think about? Then I don't think you would need to use the interim 7.1 server? Up to you. We had about 517 forms to move (plus all the workflow). It really wasn't that bad Thanks! Lisa From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Tuesday, April 10, 2012 12:25 PM To: arslist@ARSLIST.ORG Subject: Re: Transferring in-house 6.3 code to a 7.6.04 server ** If you do not have any OTB applications, I do not think you got too much to worry about. Have you customized any of the core forms? Core workflow? By that I mean forms like the User, Group, Email Engine forms, etc.. If your answer to this is no, you can go your merry way as you might have in previous versions.. If you have customized these core forms and workflow, you might want to check with BMC if they have a hash file for just the core components, so that you can create the overlay layer for those customizations. And then go your merry way with what you want to do with your in house stuff.. I really do not see much you need to put on your watch list except for integrations etc you might have done to third party tools or applications that may face the possibilities of a breakdown if they are not compatible with the new ARS application server version. Joe From: David M. Clarkmailto:david.m.cl...@tn.gov Sent: Tuesday, April 10, 2012 12:05 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Transferring in-house 6.3 code to a 7.6.04 server ** Folks, I am finally in the process of upgrading our 6.03.00 patch 017 implementation to the latest offered. By upgrade I mean a transfer between old and new servers, not on the same server. The revs are apparently too far apart to use Migrator to transfer code between, so I will be using a 7.1 server as an intermediate transfer point. Migrator 7.1 from the 6.3 box to the 7.1 box, then the latest Migrator from the 7.1 box to the 7.6.04 box. I'll also be using Export/Import tools as needed. Note that no BMC Remedy applications are involved here, though I will be loading ITSM later. My concern now is only with in-house developed code created under or compatible with version 6.3. Solaris and Oracle on both sides. Anyone ever done this or have any suggestions as to problems that I may encounter? Thanks, -David _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Transferring in-house 6.3 code to a 7.6.04 server
David, I understand you going to 7.6x on solaris, but maybe you will see issue like, what we when thru. We when from 6.3p20 to 7.5.p4 on UNIX with 10g - custom service and change environment. As Joe pointed, if you have not customized core forms: user:group, etc.. you should be good but then you may get minor errors example the user form gave us a box 4 error, which made the installer fail. Basically delete the view (not the table) that is given the issue. We did this, copy your production to test, and run the upgrade work thru the kinks. Blow the test away again, do it again, to smooth out the process and steps. This way you can work with BMC on the issues. We found the installer failed many times,.. we did a gradual, installing each component at a time, and work thru the errors. - ar servers - ardbc - area - fb - email engine (our MT is on a separate server). -- View this message in context: http://ars-action-request-system.1093659.n2.nabble.com/Transferring-in-house-6-3-code-to-a-7-6-04-server-tp7453426p7453807.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Transferring in-house 6.3 code to a 7.6.04 server
To add what JMD says, after making sure that you've transferred any customizations of the core forms, import your Groups, Roles, and users. Make sure your permissions are EXACTLY the same and you'll be ready to import your objects and data. Drew Comayagua On Tue, Apr 10, 2012 at 11:59 AM, Dee ddus...@aim.com wrote: David, I understand you going to 7.6x on solaris, but maybe you will see issue like, what we when thru. We when from 6.3p20 to 7.5.p4 on UNIX with 10g - custom service and change environment. As Joe pointed, if you have not customized core forms: user:group, etc.. you should be good but then you may get minor errors example the user form gave us a box 4 error, which made the installer fail. Basically delete the view (not the table) that is given the issue. We did this, copy your production to test, and run the upgrade work thru the kinks. Blow the test away again, do it again, to smooth out the process and steps. This way you can work with BMC on the issues. We found the installer failed many times,.. we did a gradual, installing each component at a time, and work thru the errors. - ar servers - ardbc - area - fb - email engine (our MT is on a separate server). -- View this message in context: http://ars-action-request-system.1093659.n2.nabble.com/Transferring-in-house-6-3-code-to-a-7-6-04-server-tp7453426p7453807.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Transferring in-house 6.3 code to a 7.6.04 server
Actually it should be the other way around.. It’s a good thing you pointed it out.. But thanks for pointing that out.. Its something I missed.. If installing on a new environment and migrating is your preferred upgrade option, then before you import any customization to a new server, if there were permission groups that you have created (groups with Group Type View or Change), or Roles that you have created that your forms have been added to, those need to be imported or created on the new AR System with the same Group and Role ID before you import your customizations.. Failing which you will have issues with permissions.. Joe From: Drew Shuller Sent: Tuesday, April 10, 2012 2:40 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Transferring in-house 6.3 code to a 7.6.04 server ** To add what JMD says, after making sure that you've transferred any customizations of the core forms, import your Groups, Roles, and users. Make sure your permissions are EXACTLY the same and you'll be ready to import your objects and data. Drew Comayagua On Tue, Apr 10, 2012 at 11:59 AM, Dee ddus...@aim.com wrote: David, I understand you going to 7.6x on solaris, but maybe you will see issue like, what we when thru. We when from 6.3p20 to 7.5.p4 on UNIX with 10g - custom service and change environment. As Joe pointed, if you have not customized core forms: user:group, etc.. you should be good but then you may get minor errors example the user form gave us a box 4 error, which made the installer fail. Basically delete the view (not the table) that is given the issue. We did this, copy your production to test, and run the upgrade work thru the kinks. Blow the test away again, do it again, to smooth out the process and steps. This way you can work with BMC on the issues. We found the installer failed many times,.. we did a gradual, installing each component at a time, and work thru the errors. - ar servers - ardbc - area - fb - email engine (our MT is on a separate server). -- View this message in context: http://ars-action-request-system.1093659.n2.nabble.com/Transferring-in-house-6-3-code-to-a-7-6-04-server-tp7453426p7453807.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Transferring in-house 6.3 code to a 7.6.04 server
Good call. I was pretty much shooting from the hip. Drew On Tue, Apr 10, 2012 at 12:58 PM, Joe Martin D'Souza jdso...@shyle.netwrote: ** Actually it should be the other way around.. It’s a good thing you pointed it out.. But thanks for pointing that out.. Its something I missed.. If installing on a new environment and migrating is your preferred upgrade option, then before you import any customization to a new server, if there were permission groups that you have created (groups with Group Type *View * or *Change*), or Roles that you have created that your forms have been added to, those need to be imported or created on the new AR System with the same Group and Role ID before you import your customizations.. Failing which you will have issues with permissions.. Joe *From:* Drew Shuller drew.shul...@gmail.com *Sent:* Tuesday, April 10, 2012 2:40 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Transferring in-house 6.3 code to a 7.6.04 server ** To add what JMD says, after making sure that you've transferred any customizations of the core forms, import your Groups, Roles, and users. Make sure your permissions are EXACTLY the same and you'll be ready to import your objects and data. Drew Comayagua On Tue, Apr 10, 2012 at 11:59 AM, Dee ddus...@aim.com wrote: David, I understand you going to 7.6x on solaris, but maybe you will see issue like, what we when thru. We when from 6.3p20 to 7.5.p4 on UNIX with 10g - custom service and change environment. As Joe pointed, if you have not customized core forms: user:group, etc.. you should be good but then you may get minor errors example the user form gave us a box 4 error, which made the installer fail. Basically delete the view (not the table) that is given the issue. We did this, copy your production to test, and run the upgrade work thru the kinks. Blow the test away again, do it again, to smooth out the process and steps. This way you can work with BMC on the issues. We found the installer failed many times,.. we did a gradual, installing each component at a time, and work thru the errors. - ar servers - ardbc - area - fb - email engine (our MT is on a separate server). -- View this message in context: http://ars-action-request-system.1093659.n2.nabble.com/Transferring-in-house-6-3-code-to-a-7-6-04-server-tp7453426p7453807.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Transferring in-house 6.3 code to a 7.6.04 server
We did an upgrade (mis-nomer) last year. After 3 months of trying to upgrade we ended up just creating new servers and export/importing objects. The biggest gotcha we ran into was when you import forms to the new database it changes the form ID (T236 became T450). Any sql statements included in workflow needed to be updated and external programs needed to be updated. There were other things and if you take the time to search archives I described them pretty extensively. Good luck!! Susan On Tue, Apr 10, 2012 at 11:05 AM, David M. Clark david.m.cl...@tn.govwrote: ** Folks, ** ** I am finally in the process of upgrading our 6.03.00 patch 017 implementation to the latest offered. By “upgrade” I mean a transfer between old and new servers, not on the same server. The revs are apparently too far apart to use Migrator to transfer code between, so I will be using a 7.1 server as an intermediate transfer point. Migrator 7.1 from the 6.3 box to the 7.1 box, then the latest Migrator from the 7.1 box to the 7.6.04 box. I’ll also be using Export/Import tools as needed. Note that no BMC Remedy applications are involved here, though I will be loading ITSM later. My concern now is only with in-house developed code created under or compatible with version 6.3. Solaris and Oracle on both sides.** ** ** ** Anyone ever done this or have any suggestions as to problems that I may encounter? ** ** Thanks, ** ** -David _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Transferring in-house 6.3 code to a 7.6.04 server
A very useful tip: Many of you may know this.. If you MUST write a Direct SQL, you NEVER should write SQL directly to T tables.. Instead write them against the view name.. for eg if you wanted to write one for the HPD:HelpDesk form whose table is lets say T654 do not write it to T654.. Describe HPD_HelpDesk and write it to that.. Then the upgrade would be seamless as the view name never changes.. You may want to consider a project where if you have Direct SQL’s to the T tables, convert them to address the view names.. Joe From: Susan Palmer Sent: Tuesday, April 10, 2012 7:57 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Transferring in-house 6.3 code to a 7.6.04 server ** We did an upgrade (mis-nomer) last year. After 3 months of trying to upgrade we ended up just creating new servers and export/importing objects. The biggest gotcha we ran into was when you import forms to the new database it changes the form ID (T236 became T450). Any sql statements included in workflow needed to be updated and external programs needed to be updated. There were other things and if you take the time to search archives I described them pretty extensively. Good luck!! Susan On Tue, Apr 10, 2012 at 11:05 AM, David M. Clark david.m.cl...@tn.gov wrote: ** Folks, I am finally in the process of upgrading our 6.03.00 patch 017 implementation to the latest offered. By “upgrade” I mean a transfer between old and new servers, not on the same server. The revs are apparently too far apart to use Migrator to transfer code between, so I will be using a 7.1 server as an intermediate transfer point. Migrator 7.1 from the 6.3 box to the 7.1 box, then the latest Migrator from the 7.1 box to the 7.6.04 box. I’ll also be using Export/Import tools as needed. Note that no BMC Remedy applications are involved here, though I will be loading ITSM later. My concern now is only with in-house developed code created under or compatible with version 6.3. Solaris and Oracle on both sides. Anyone ever done this or have any suggestions as to problems that I may encounter? Thanks, -David ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
