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 <[email protected]> To: [email protected] 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 <[email protected]> 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 <[email protected]> > To: [email protected] > 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 at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
