From: "Robert Comer" 

>So that is really an
> excellent idea, thanks.    :)

You're welcome. That's how I'd do it anyway and have done something similar
though the other way around. (the server talking to standalone PC's to
generate reports and such.)

>probably 3A is.

Could be, it's not something I have experience with.

- Bob Comer


"Ellen K."  wrote in message
news:jd9ba1h9rsuuvh5bqbnj720qf2gha71a9n{at}4ax.com...
> 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