Agreed... I am now begining this tedious task of determining if there are any server references embedded in the workflow and forms that cannot be displayed.
Thanks Joe. On Jul 15, 2:38 pm, Joe DeSouza <joe_rem...@yahoo.com> wrote: > The only way to check for server references is exporting the definitions and > looking for server names in those definitions. Everything looks normal viewing > these objects through the Admin or the Developer tool.. Personally I prefer > XML > definitions as its easier to edit these from XML files and not worrying > about string lengths and all that good stuff.. > > Sometimes you cannot blame your developers if server names have still crept > in, > as with some versions of the older Admin tool, there were bugs, where certain > workflow objects would save the server names instead of making them server > independent when those objects were created of modified. I have not quite > seen a > pattern on when and how these server names creep in, but did notice that using > the IP Address as the server name in the Accounts while connecting to the > server, can cause these kind of issues and would save the IP address instead > of @ in the database. > > Joe > > ________________________________ > From: Elry <elryal...@gmail.com> > To: arsl...@arslist.org > Sent: Thu, July 15, 2010 11:50:26 AM > Subject: Re: SQL Database Replication > > Thanks Joe... > > The application that we are using is not ITSM. It is a custom application > that > we have built. > > All the developers were warned not to hard-code server names, but I have never > actually checked for this ( I will now). > > We are not using AIE or LDAP. > > I did not alter the ar.cfg file - shoud we try starting it up with the ar.cfg > adapted to look like the original? > > On Jul 15, 11:44 am, Joe DeSouza <joe_rem...@yahoo.com> wrote: > > > > > > > Elry, > > > One of the reasons answers differ and vary is the configuration. All depends > on > > what applications you are using. Does the application have configuration > > data that hard codes server names like AIE would in its configuration. Some > > applications store some environment specific information like LDAP server > names > > and login credentials. Then there are odd cases where under certain > > conditions > > you get server names or IP Addresses of the server hardcoded into workflow > such > > as table fields. Sometimes you need to consider looking up the meta data and > > make sure you do not have hard coded server name references in workflow. > > > So for the most part, yes a simple backup and restore of the database works > > directly unless you need to tweak some of the application or configuration > data > > and meta data to remove hard coded or wrong server references. Also if you > > choose to replicate the ar.cfg file, make sure you point that file to the > right > > database server, or you might end up having a test server point to > >production... > > > Joe > > > ________________________________ > > From: Elry <elryal...@gmail.com> > > To: arsl...@arslist.org > > Sent: Thu, July 15, 2010 8:46:57 AM > > Subject: SQL Database Replication > > > Hi Folks... > > > I am going to ask this question again - because I have never seen a > > definitive > > answer. > > > Here is what we have: > > > 1) Independent SQL Database Tier (2005). > > 2) ARSystem Application Tier (7.5 Patch 2). > > 3) Mid-tier (7.5 Patch 2). > > > Environments: > > > 1) Sandbox > > 2) Development > > 3) Staging > > 4) Production > > 5) Reporting/Archiving (to be deployed). > > > What we need to do is the following: > > > 1) Update the Staging and Development environments with data from production > > 2) Replicate the Production database to our new Reporting/Archiving > >environment. > > > Options being considered: > > > A) Database Replication. > > B) BMC Remedy Migrator. > > C) DSO. > > > We understand and know how to use options B) and C). We are looking > > for feedback from anyone who is successfully using option A). > > Specifically... > > > 1) What type of replication. > > 2) Are there configuration paramaters that are retained at the database > > level > > that need to be changed. > > 3) Are there any considerations for ar.cfg. > > > I have never seen a white paper on database replication ( I understand that > >this > > method is unsupported). > > > Any feedback would be greatly appreciated. > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > attend wwrug10www.wwrug.comARSlist: "Where the Answers Are"- Hide quoted text > - > > - Show quoted text - _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
