Monday, March 12, 2012

I am referring to SQL SERVER 2005

I am referring to SQL SERVER 2005Abhi,
is this a reference to my reply? If so, I am also talking about SQL Server
2005 - RMO is the new API in SQL 2005, while SQLDMO is the 2000 one (see
http://msdn2.microsoft.com/en-us/library/ms223018(en-US,SQL.90).aspx).
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hello Paul,
Thanks for the quick reply. I wanted to know that while deploying our
replication implementation along with our software, how to package the
correct set of necessary assemblies along with our client to ensure that the
software can function correctly. That is how to include the required
assemblies in with the client such that the software works properly.
Please give some information
"Paul Ibison" wrote:

> Abhi,
> is this a reference to my reply? If so, I am also talking about SQL Server
> 2005 - RMO is the new API in SQL 2005, while SQLDMO is the 2000 one (see
> http://msdn2.microsoft.com/en-us/library/ms223018(en-US,SQL.90).aspx).
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Abhi,
now I'm confused
The necessary replication infrastructure will already be on the SQL Server
2005 installation at the clien't site in the form of system stored
procedures - replication is not a set of assemblies that need to be
installed separately. Having the client set up as a subscriber to your
publication will be an executable that uses RDO to interact with the SQL
Server 2005 installation - the RDO libraries will already be there. In that
sense, the only assembly you'll need is your own one. How this code is run
is your own choice - an executable run by the client, a windows installation
package etc. If you want to make it even simpler and avoid RDO, just script
out the pull subscription in the form of stored procedure calls, and use the
Command object to run the script.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul,
Actually i am confused myself. My client has raised this question... i am
forwarding to you as it is... just read it and tell me wat do you have to
say about it..
"We are ready to start deploying our replication implementation along with
our software. One of the issues we are struggling with is how to package the
correct set of necessary assemblies along with our client to ensure that the
software can function correctly. Is MS planning to provide a merge module or
similar for the replication featureset? The main issue we have encountered
so far is that if we attempt to include the SQL Server assemblies we are
using from the SDK directory, we get some internal security token errors. I
can provide more details as necessary. I guess the question is what is the
recommended deployment model for stand-alone clients which are replicating
between a local and remote server where the local doesn't include an install
of the SQL management tools? (It will have express."
This is wat has been asked... Please give your suggestions
Thanks
Abhi
"Paul Ibison" wrote:

> Abhi,
> now I'm confused
> The necessary replication infrastructure will already be on the SQL Server
> 2005 installation at the clien't site in the form of system stored
> procedures - replication is not a set of assemblies that need to be
> installed separately. Having the client set up as a subscriber to your
> publication will be an executable that uses RDO to interact with the SQL
> Server 2005 installation - the RDO libraries will already be there. In that
> sense, the only assembly you'll need is your own one. How this code is run
> is your own choice - an executable run by the client, a windows installation
> package etc. If you want to make it even simpler and avoid RDO, just script
> out the pull subscription in the form of stored procedure calls, and use the
> Command object to run the script.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
>
|||Abhi,
I haven't done this, but my understanding is that provided you have SQL
Server Express on the client, there's no need to add any SQL
Replication-specific assemblies to your installation routine - the
replication features are inbuilt into the already installed SQL Engine.
Setting up the pull subscription can be done using RMO which will also be on
the client, or using stored proc calls - again already on the client.
Syncing relies on either your own (RMO) routine, or Windows Sync Manager. If
in any doubt, give it a try - I don't have a setup here, but it should be
simple enough if you have a SQL Server Express installation.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hey Paul,
Thanks a lot. This is exactly what i was wondering that why he needs to
include SQL SDK Assenblies in his application. Meanwhile i have installed SQL
Server Express and it does contain "Microsoft.SqlServer.Replication.dll" in
location - "C:\Program Files\Microsoft SQL Server\90\SDK\Assemblies". Hence,
I think there is no need to include these assemblies. What do you think?
Thanks
Abhi
"Paul Ibison" wrote:

> Abhi,
> I haven't done this, but my understanding is that provided you have SQL
> Server Express on the client, there's no need to add any SQL
> Replication-specific assemblies to your installation routine - the
> replication features are inbuilt into the already installed SQL Engine.
> Setting up the pull subscription can be done using RMO which will also be on
> the client, or using stored proc calls - again already on the client.
> Syncing relies on either your own (RMO) routine, or Windows Sync Manager. If
> in any doubt, give it a try - I don't have a setup here, but it should be
> simple enough if you have a SQL Server Express installation.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Abhi,
I totally agree. Unfortunately I can't confirm this empirically by using my
current setup, but please let us know if this is correct in practice.
Cheers,
Paul Ibison

No comments:

Post a Comment