At 13.48 14/12/2001 -0500, you wrote:

>If your using super-server, it should automatically restart itself, so
>the question becomes what happens if the server dies at the O/S
>level, such as the O/S crashing (Windows) or a hardware failure
>(Windows or Unix). There should be various failover systems, not
>sure about PC/Linux stuff, I am sure Microsoft has a $50,000
>sollution, that works half the time, and means you need to upgrade
>to W2K Enterprise.. Ssome of the main-line Unixes have
>automated failover systems, although you could probably fake it, in
>software.
>
>The primary server could write a heart-beat file, it needs to write
>this on the secondary servers file system, it writes the file every 15
>seconds, the secondary server then checks the file every 15
>seconds, if it's more then 60 seconds old, then it assumes the
>primary has failed, and updates DNS to point the primaries name
>to itself, and restarts DNS. Workstations only need to know that if
>they lose their connection to reconnect. Of course you need some
>form of replication so that the secondary and primary servers are
>kept up to date with each other.

The $50,000 solution is a bit different....
the cluster is seen as a single IP.
When you connect to that IP you are automatically connected to the right
server.
If one server goes down only the current connection is lost,
your client doesn't know which are the real IP ....
they connect always to the same IP.
I think that this solution is a bit more simple than the
one described by you.
Also I think that the failover and replication should be implemented
at the SQL Server level.
But I understand that this isn't simple to do....
and I don't know how to do it.
I think that also a modified "external interface" can be done
if we have three servers the interface will spawn the inserts / updates /
deletes
on the three servers and will do the selects on the less heavy-used server.
But this is simple to tell but not simple to implement.
My two cents,
Marco