Need help here.

We need to have two database servers in separate facilities kept up to date.
With a disaster we start using the second one.

SQL replication won't do it because not all tables have primary keys.
Data mirror won't work for the same reason.
Likewise Lakeview Tech.

Anyone have any thoughts on how we can do this? Livevault is one thought we
have. Doesn't EMC have something for hardware based replication?
--

burt_king (AT) yahoo (DOT) com

--
burt_king (AT) yahoo (DOT) com

Look at DoubleTake - its much cheaper than RepliStore - EMC's offering.

You may also be able to add primary keys - there must be a candidate key
somewhere otherwise how will you know what row to update or delete? You may
be able to have the application talk to a view which looks the same as the
current tables, and then have the base tables of the view with PKs (this
only works is the tables are small). Merge replication or snapshot
replication may also work for you.

--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html

Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com

"burt_king" <burt_king (AT) yahoo (DOT) com> wrote

Purchase the application thus we're not going to modify it.
--
burt_king (AT) yahoo (DOT) com


"Hilary Cotter" wrote:

Many apps are insensitive to adding a pk. I'd try it and see what happens.

--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html

Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com

"burt_king" <burt_king (AT) yahoo (DOT) com> wrote

Not a chance we're adding primary keys. Upgrades in the future could be
disasterous. Never gonna happen as long as there's O2 in my lungs.
--
burt_king (AT) yahoo (DOT) com


"Hilary Cotter" wrote:

I hate to jump into the middle of a thread, but this sounds like a problem
that I've already messed up. <g> On the suggestion of a consultant, we set
up SQL2000 to replicate to a backup server. What I didn't know, was that
SQL would install rowguid columns in each table. This has been a real
problem. The thirdparty application that we use as the frontend calls their
fields by column number, not name. Likewise, the first upgrade that I tried
to install was disasterous. I somehow am lucky enough to have the system
stable at the moment, but can't install any upgrades. We are now looking at
Doubletake, but I am not able to remove the rowguid columns from the tables.
I found some info on a website called www.replicationanswers.com. It
removes the rowguid columns, but the application won't run, probably due to
missing indexes and contraints.

Anyone have an idea how to get back to 'normal' so that we can try out
DoubleTake?

Help!

John

"Hilary Cotter" <hilary.cotter (AT) gmail (DOT) com> wrote

Something doesn't make any sense. The application ran before having the
rowguids added, failed after they were added, was fixed so that it ran
again, and now removing them causes the application to fail.

The first part is getting the database structure back to what the
application accepts. Can't tell you how to do that, because I don't know
what your existing structure is or what the application is expecting.

This also doesn't mean you can't use replication. Merge is obviously not
going to work, because it changes the table structure which messes up your
application. That also rules out queued updating. If all of the tables
have primary keys, then you can still use transactional replication.

I would definitely recommend not going back to that "consultant" again.
They definitely did not do their job since their proposed solution very
obviously missed some key points which created a disaster in your
environment. (Yes, it should have been tested before being put into
production, but it's also the "consultants" job to do a full analysis before
making a recommendation.)

--
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.


"countryhouse" <countryhouse (AT) comcast (DOT) net> wrote

It sounds like these objects are still marked for replication. If this is
the only publication in this db and there are no subscriptions there can you
try the following

DECLARE @name varchar(129)
DECLARE list_replicated_tables CURSOR FOR
SELECT name FROM sysobjects WHERE replinfo <>0
UNION
SELECT name FROM sysmergearticles


OPEN list_replicated_tables


FETCH NEXT FROM list_replicated_tables INTO @name
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT 'unmarking replicated table ' +@name
--select @name='drop Table ' + @name
EXEC sp_msunmarkreplinfo @name
FETCH NEXT FROM list_replicated_tables INTO @name
END
CLOSE list_replicated_tables
DEALLOCATE list_replicated_tables


GO


UPDATE syscolumns set colstat = colstat & ~4096 WHERE
colstat &4096 <>0
GO
UPDATE sysobjects set replinfo=0
GO



--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html

Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com

"countryhouse" <countryhouse (AT) comcast (DOT) net> wrote