Replication over FTP

Hey guys.
Really stuck in a jam on this one.
SQL subscriber is behind a firewall, so FTP snapshots don't work. From
behind the firewall you can only connect to an external FTP server and
transfer data via FTP Passive mode. I can't find anywhere a setting for SQL
2000 to use passive mode.
Does anyone at all know if SQL 2000 does not support passive mode in any way?
Does anyone know a solution for this problem. We don't want to do VPN
because then we have to give each location direct access to our network. Is
there an option I'm perhaps missing here?
Thanks in advance.
Take care.
You could write a script that connects with an FTP server download the
required snapshot files, and then have SQL Server apply the snapshot from
an alternate location. You will see this option when you pull your
subscription.
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
|||Could I get an explination for what the snapshots are for?
I believe their only for initialization correct? Not the actual replication
merging, that happens on the 1433 port connection?
If so..
Can I, when setting up the database, export all objects to the server. Then
create the subscription, and I've tried to take the initialization step off
in the wizard, saying "subscriber already has schema" etc.
Then when I try and start the pull subscription I get this history in the
job history:
Bulk copying data into table 'sysmergesubsetfilters'
Message: The process could not deliver the snapshot to the Subscriber.
Message: The process could not bulk copy into table
'"dbo"."MSmerge_contents"'.
Message: Unable to open BCP host data-file
The process could not deliver the snapshot to the Subscriber. The step
failed.
Is my idea possible? Not use any snapshots if the server can already be
populated with the data via export?
Thanks for all the help!
"Hilary Cotter" wrote:

> You could write a script that connects with an FTP server download the
> required snapshot files, and then have SQL Server apply the snapshot from
> an alternate location. You will see this option when you pull your
> subscription.
> --
> 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
>
|||the snapshots are to create the schema on the subscriber and push the data
there. It also contains replication metadata which is normally used for
tracking. So, yes, it is for initialization. All replication activity takes
place over port 1433 except for the application of the snapshot which is
pulled or pushed through a unc or ftp port.
Unfortunately with merge replication even a no-sync snapshot requires a mini
snapshot to be deployed and applied on the subscriber. Transactional
replication uses pure sql statements to create the metadata tables and
populate them with the required data.
"Synced" <Synced@.discussions.microsoft.com> wrote in message
news:1C666DCB-2FEF-4A5E-B142-0DC52A3AE75B@.microsoft.com...[vbcol=seagreen]
> Could I get an explination for what the snapshots are for?
> I believe their only for initialization correct? Not the actual
> replication
> merging, that happens on the 1433 port connection?
> If so..
> Can I, when setting up the database, export all objects to the server.
> Then
> create the subscription, and I've tried to take the initialization step
> off
> in the wizard, saying "subscriber already has schema" etc.
> Then when I try and start the pull subscription I get this history in the
> job history:
> Bulk copying data into table 'sysmergesubsetfilters'
> Message: The process could not deliver the snapshot to the Subscriber.
> Message: The process could not bulk copy into table
> '"dbo"."MSmerge_contents"'.
> Message: Unable to open BCP host data-file
> The process could not deliver the snapshot to the Subscriber. The step
> failed.
> Is my idea possible? Not use any snapshots if the server can already be
> populated with the data via export?
> Thanks for all the help!
> "Hilary Cotter" wrote:
|||Hey Hilary,
Thanks a ton for the reply. So again I hit another bind.
Let me explain my situation. My publisher, when setting up the replication,
will have no data. The subscriber, a pull merge subscription, has all the
data/schema.
Reason for this is, subscribers can't open listening ports on firewalls, so
I'm making them the "puller".
This is all working now with your guidance, the only problem is, when the
subscriber applies snapshots in a manual location just to get the merge
going, because you said its required, it wipes out all the data on the
subscriber applying the snapshots.
What I really want is for the subscriber to push all the data to the
publisher, and from then on they merge continiously.
Is this possible? Or do I have to export all data to the publisher, make
snapshots, and then the subscriber basically because of the snapshots wipes
out its own data, and re-applies it through the snapshot?
Thanks for all the help.
"Hilary Cotter" wrote:

> the snapshots are to create the schema on the subscriber and push the data
> there. It also contains replication metadata which is normally used for
> tracking. So, yes, it is for initialization. All replication activity takes
> place over port 1433 except for the application of the snapshot which is
> pulled or pushed through a unc or ftp port.
> Unfortunately with merge replication even a no-sync snapshot requires a mini
> snapshot to be deployed and applied on the subscriber. Transactional
> replication uses pure sql statements to create the metadata tables and
> populate them with the required data.
> "Synced" <Synced@.discussions.microsoft.com> wrote in message
> news:1C666DCB-2FEF-4A5E-B142-0DC52A3AE75B@.microsoft.com...
>
>