Re: HDR and Client Redirection

Karl Ostner said: > Joachim, > > you can do it this way: > > sqlhosts file: > myServer group - - > myServer1 onsoctcp myHost1 myPort1 g=myServer > myServer2 onsoctcp myHost2 myPort2 g=myServer > > setup HDR pair using myServer1 and myServer2. > > for your client, set INFORMIXSERVER=myServer That is documented to work as far as ER is concerned, but TFM does not explicitly say that it's OK for application use. I would love this to work for everything, can someone confirm whether it's a documentation issue or whether it's not supported for application use. -- Bye now, Obnoxio "It's easier with pictures." -- Cosmo "But wait, it gets worse." -- Cosmo "Run, don't walk, for the nearest exit." -- Cosmo

Obnoxio The Clown wrote: > Karl Ostner said: > >>Joachim, >> >>you can do it this way: >> >>sqlhosts file: >>myServer group - - >>myServer1 onsoctcp myHost1 myPort1 g=myServer >>myServer2 onsoctcp myHost2 myPort2 g=myServer >> >>setup HDR pair using myServer1 and myServer2. >> >>for your client, set INFORMIXSERVER=myServer > > > That is documented to work as far as ER is concerned, but TFM does not > explicitly say that it's OK for application use. I would love this to work > for everything, can someone confirm whether it's a documentation issue or > whether it's not supported for application use. > No, I can't. But it seems to work for Art, and I'm sure he has a stricter environment than most... "Taking care of Fail Back in HDR" <http://groups.google.co.uk/group/comp.databases.informix/browse_frm/thread/4808b19991edb2e7/a414783c8f7c9649?q=Taking+care+of+Fail+Back+in+HDR&rnum=1#a414783c8f7c9649>; Art Kagel wrote: #There is another option. Define a group in the sqlhosts file, much as #you would from ER, include both servers in the group with the primary #server listed first. Make the 'e=' entry name the backup server. When #the primary goes down any application just needs to reconnect when it #detects the loss of connection, reprepare any statements and redeclare #cursors and voila! You're back in business. and: #OH! Forgot to mention. You would set INFORMIXSERVER or the #'@servername' clause in a CONNECT TO statement to point to the group #rather than one of the replicants.

Richard Harnden said: > Obnoxio The Clown wrote: >> Karl Ostner said: >> >>>Joachim, >>> >>>you can do it this way: >>> >>>sqlhosts file: >>>myServer group - - >>>myServer1 onsoctcp myHost1 myPort1 g=myServer >>>myServer2 onsoctcp myHost2 myPort2 g=myServer >>> >>>setup HDR pair using myServer1 and myServer2. >>> >>>for your client, set INFORMIXSERVER=myServer >> >> >> That is documented to work as far as ER is concerned, but TFM does not >> explicitly say that it's OK for application use. I would love this to >> work >> for everything, can someone confirm whether it's a documentation issue >> or >> whether it's not supported for application use. >> > > No, I can't. > > But it seems to work for Art, and I'm sure he has a stricter environment > than most... > > "Taking care of Fail Back in HDR" > > <http://groups.google.co.uk/group/comp.databases.informix/browse_frm/thread/4808b19991edb2e7/a414783c8f7c9649?q=Taking+care+of+Fail+Back+in+HDR&rnum=1#a414783c8f7c9649>; > > Art Kagel wrote: > #There is another option. Define a group in the sqlhosts file, much as > #you would from ER, include both servers in the group with the primary > #server listed first. Make the 'e=' entry name the backup server. When > #the primary goes down any application just needs to reconnect when it > #detects the loss of connection, reprepare any statements and redeclare > #cursors and voila! You're back in business. > > and: > #OH! Forgot to mention. You would set INFORMIXSERVER or the > #'@servername' clause in a CONNECT TO statement to point to the group > #rather than one of the replicants. So, it's a document omission, then? -- Bye now, Obnoxio "It's easier with pictures." -- Cosmo "But wait, it gets worse." -- Cosmo "Run, don't walk, for the nearest exit." -- Cosmo