DSO operations for "insert/update" trigger filters which are set for "Merge" action. Hopefully you already went through and sanity checked all workflow, that triggers on Merge. example would be say SHR:Categorization where you might need to import an excel-sheet of data, and you need to cascade possibly into other forms. To exclude DSO Server, you would put in $USER$ != "Distributed Server"...
For distributed Delete operations, it does trigger filters set for "Delete" action, so the above also holds true. So, if it is setup properly, you 'should already be able to' use the system as a fail over server, as long as you have a mechanism to get any "new/updated" tickets back onto the source server once it is back online. However, I do not personall like this setup, because of the possiblity of "user error", logging into the wrong system, etc. If you need a 100% online system, you should think about a high-availibility DB Server (like Microsoft SQL Cluster, or Oracle Cluster), and then load-ballance two ARServers to connect to the single DB. If you have VMWare in-house this is perfect application for it, because you build your server, and clone it to as many load-ballanced-servers as capacity dictates. HTH On 10/4/07, Frank Caruso <[EMAIL PROTECTED]> wrote: > > ** > Have an ARS server which is using DSO to push data to another ARS server > which is being used as both a reporting server and a fail over solution. > What I don't want to happen is have filters fire on the replicate server as > new and updated records are being processed. > > I suppose the simple solution would be to create a filter that is on every > form that just does a Goto Execution order of 1000. Although I would have to > remember to do this if we did fail over. > > Thoughts? > > Thank you. > > Frank > __20060125_______________________This posting was submitted with HTML in > it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
