Author Topic: SQL Server replication - anyone tried it?  (Read 1823 times)

Dave_Bullet

  • EA User
  • **
  • Posts: 295
  • Karma: +0/-0
    • View Profile
SQL Server replication - anyone tried it?
« on: January 14, 2007, 01:59:08 pm »
We have an architecture team in 3 locations, needing to access the same SQL Server EA model.

Performance of EA for remote users is poor by comparison to users local to the database server.

My idea is to implement merge replication for SQL Server (we are still SQL Server 2000) between sites.

Has anyone tried this under EA?  IF so - can you please let me know your findings.

Sparx - do you have any experience using SQL Server replication under an EA model?  Do you support it?

Thanks,
DAvid.
"I know I'm close to a good design, but it's like the balloon animals, squeeze in one spot and the problem moves down the line"

Dave_Bullet

  • EA User
  • **
  • Posts: 295
  • Karma: +0/-0
    • View Profile
Re: SQL Server replication - anyone tried it?
« Reply #1 on: January 22, 2007, 02:37:36 pm »
FYI...

(incase anyone wants to know....)

-> Have you got a geographically dispersed team?
-> Are you using an RDBMS (specifically MS SQL Server) as your corporate project repository?
-> Do you find performance is poor with EA over latent WAN links?

Then create local DBs wherever your users are and setup SQL Server merge replication between sites.

I've got this working under EA (well - between 2 databases anyway).  EA doesn't seem to mind.

Steps are:
1. Rework the base SQL script supplied by Sparx to create your EA tables, and add "NOT FOR REPLICATION" to all identity columns
2. Run the script - populate your repository etc...
3. Create a single publication on one of your SQL server DBs with all the EA tables added.  Make sure when you add articles (the tables) - you specify manage identity info automatically - and specify ranges.  I find 10,000 adequate.  Also make sure you specify "no" on each table's merging changes option for multi column updates.  This ensures SQL server will generate a single update for each column - minimising same row update conflicts
4. Create a subscription on a remote database.  Either continuous or scheduled (doesn't matter) - I'm using continuous FWIW.

cavaets:
1. bandwidth required will vary depending on activity - could be detrimental to your other WAN traffic
2. I don't know how version control impacts the above (I don't use VC on my EA model).

Cheers,
DAvid.
"I know I'm close to a good design, but it's like the balloon animals, squeeze in one spot and the problem moves down the line"