From: Ellen K. 

If we were talking client/server, yes, except that the way we are doing it
for client/server is connect at log-on and stay connected, the users don't
make a new connection for every interaction with the database. Still, you
could have a standard function that all your error handlers call so that if
the connection isn't there any more, set the existing one to Nothing and
connect to the alternate.  So that is really an excellent idea, thanks.   
:)

Don't know how it works in a "service-oriented architecture"
using an "enterprise service bus", but anyway I don't think 3B is
the difficult one in the replication scenario, probably 3A is.

On Tue, 7 Jun 2005 09:33:27 -0400, "Robert Comer"
 wrote in message
:

>Couldn't 3B be handle just be error handlers in your code, say if ODBC
>connect fails, try secondary?  Switching back is easy if you always have it
>try the primary first.
>
>Updating the primary might be a problem though...
>
>- Bob comer
>
>
>"Ellen K."  wrote in message
>news:ie6ba115e14taiisp3cijopdlngsgtmlp0{at}4ax.com...
>>I guess that is an apology, so I have to forgive you.
>>
>> You are smart enough to read the post to fully understand the
>> requirements that need to be met, rather than immediately pole-vaulting
>> to the conclusion that Microsoft is the problem.
>>
>> For the record:
>> 1.  I am in charge of the SQL Server databases, not any other servers.
>>
>> 2.  Microsoft has server clustering.  SQL Server clustering requires
>> Microsoft server clustering.  Clustering doesn't meet the requirements
>> because the clustered machines share a disk array, if the disk array is
>> in the location where the disaster occurs I'm still toast.  Distance
>> clustering, which Microsoft also supports, doesn't solve this.
>>
>> 3.  Replication might meet the requirements if I can figure out how to
>>     A.  quickly transform the erstwhile Subscriber into a standalone
>> database;
>>     B.  get the user apps to point at the erstwhile Subscriber within a
>> reasonable timeframe;
>>     C.  get back to the status quo ante (= restore or re-create the
>> Publisher from the former Subscriber) after the smoke clears.
>>
>> 4.  Log shipping would be even better than replication because 3 A and C
>> are handled by system stored procedures, but 3B would still have to be
>> solved (although I think that's the least of it given the new setup with
>> the ESB), AND there is a BIG additional wrinkle which is that one of the
>> databases holds BLOB data... AFAIK BLOB data are stored on their own
>> pages, the BLOB field only holds a pointer to the location of the actual
>> data, and only the pointer gets written to the log.  So unless log
>> shipping actually reads MORE than the log, I have a problem.  Therefore,
>> to use log shipping I would need to come up with a way to deal with the
>> BLOB data.   I am going to post a question on the SQL Server newsgroup
>> to see if anyone knows for sure what happens to BLOB data when log
>> shipping is used.
>>
>> Now, if you have any suggestions that meet the requirements, I'm all
>> ears.   :)
>>
>> On Mon, 06 Jun 2005 17:16:52 -0400, Mike '/m'
 wrote in
>> message :
>>
>>>
>>>I was only commenting upon the narrow-mindedness of Microsoft solutions
>>>and the OS's they run on.
>>>
>>>Didn't mean to get your dander up.
>>>
>>> /m
>>>
>>>On Sun, 05 Jun 2005 19:00:07 -0700, Ellen K.

>>>wrote:
>>>
>>>>Oh please.
>>>>
>>>>Why should my company invest megabucks in operating systems
for which we
>>>>have no knowledgable resources?   Just because you hate Microsoft?
>>>>What makes you think the other, non-Microsoft, pieces of
our new setup
>>>>run on that?
>>>>
>>>>
>>>>On Sun, 05 Jun 2005 21:47:02 -0400, Mike '/m'
 wrote in
>>>>message :
>>>>
>>>>>On Sun, 05 Jun 2005 18:21:37 -0700, Ellen K.

>>>>>wrote:
>>>>>
>>>>>>my *SQL SERVER DATABASES*, so solutions requiring
other than Windows
>>>>>> operating systems aren't really solutions.
>>>>>
>>>>>Such is often the problem with Microsoft
"solutions"....
>>>>>
>>>>>
>>>>>
>>>>> /m
>>
>

--- BBBS/NT v4.01 Flag-5