Re: Merge replication in 'SQL Server'
- From: "Hilary Cotter" <hilary.cotter@xxxxxxxxx>
- Date: Wed, 6 Jul 2005 06:39:16 -0400
1) no problem, you can configure sql server to run on any port - have a
look at http://support.microsoft.com/default.aspx?scid=kb;en-us;823938 in
the section marked. However, port 443 is for https, did you want your SQL
Server traffic encrypted?
Configuring an instance of SQL Server to use a static port
2) you can script out replication jobs by right clicking on a publication
and selecting - generate sql script. You can generate the scripts necessary
to enable replication by right clicking on the replication folder and
selecting Generate SQL Scripts, and then selecting Distributor properties.
3) you can configure autorun.inf to run an executable which will run the
scripts generated above
Everything you list is possible - you suddenly start talking about SQL CE -
if your clients are running SQL CE, you will need a web server to
synchronize with. You could run over port 443 for this. I would not
characterize "Merge replication in the SQL Server is good in theory but
difficult to manage and requires a lot of extra handling issues like opening
ports and adding users granted to run the processes for the replication
process."
This is simply not true. Merge replication or any form of replication only
needs port 1433 (or whatever port you run SQL Server on) open. If you are
deploying your snapshot over the internet you will probably want port 21
open as well. Regarding the addition of users, this could be valid. You can
run pull agents on the subscribers which will connect to the publisher under
different accounts if you are doing filtering by suser_name(). But by
default you probably would not have to do this. I normally use pass through
authentication which uses the same account names.
There are lots of improvements, fixes, and features in SQL 2005. Web
synchronization is one of them. Although the documentation talks about
running over port 1433 (https) in addition to 80(http), I believe this is a
mistake.
I worked on a replication topology with over 60 merge clients. We had our
share of problems, but in general it was highly stable.
--
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
"Gil" <Gil@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:123D2E11-371E-419E-8B5F-D4710F95A008@xxxxxxxxxxxxxxxx
> Hi,
> I read Paul Ibison's article about "Replication Across Non-Trusted Domains
> or Using the Internet".
>
> Me (and my company) need to take a very tough decision whether using SQL
> server 2005 merge replication or building our own synchronization engine.
> Our big problems are:
>
> 1. Everything has to work over the internet (over port 443 only), even
port
> 21 for ftp is not an issue.
> 2. Out product is for customers overseas without the ability to go through
> an integration process at the client site. It means we must use some
> automatic process configuring the publisher or subscriber and users
running
> processes, etc.
> 3. The installation must work from an installation cd (both client and
> server), without the need to manually configure domain users to run
certain
> replication agents - it must also be automatically.
>
> Which one (or all) of the demands above is possible??
> We are willing to make small changes -only after we definitely know that
we
> must open port 21 for example.
>
> I understood that the implementation of offline clients (doesn't matter if
> it's PDA with SQL CE/Mobile or windows XP with MSDE/Express) and Merge
> replication in the SQL Server is good in theory but difficult to manage
and
> requires a lot of extra handling issues like opening ports and adding
users
> granted to run the processes for the replication process.
>
> Are there any improvements in 2005 in these issues (I know about the
option
> to replicate through iis so the port problem is now solved?!).
>
> My most important request is that I'll be glad if anybody knows and can
> write about products in the open market which used this architecture.
>
> Thanks,
> Gil.
>
>
> I'm in a crucial
>
> Is it true? Are there any improvements in 2005 in these issues (I know
about
> the option to replicate through iis so the port problem is now solved?!).
> I'll be glad if anybody knows and can write about products in the open
> market which used this architecture.
>
> Thanks,
> Gil.
>
>
>
.
- Follow-Ups:
- Re: Merge replication in 'SQL Server'
- From: Paul Ibison
- Re: Merge replication in 'SQL Server'
- From: Gil
- Re: Merge replication in 'SQL Server'
- References:
- Merge replication in 'SQL Server'
- From: Gil
- Merge replication in 'SQL Server'
- Prev by Date: Snapshot replication involving large table - 17million+ rows
- Next by Date: Re: The SQL Server cannot obtain a LOCK resource at this time.
- Previous by thread: Merge replication in 'SQL Server'
- Next by thread: Re: Merge replication in 'SQL Server'
- Index(es):
Relevant Pages
|
