Does SQL Server 2005 Express have a SQL Agent

Does SQL Server 2005 Express have a SQL Agent? If so, can someone tell me where I would find it? If not, can someone tell me if there is a replacement for it or some kind of work around?

Thanks,

John

There is not.

Call a stored procedure when someone logs in to see if something needs to be run.

|||

I was afraid that was the situation. I couldn't find anything on it and I finally found a MSN page that showed the feature comparisons on the varions SQL Servers and I saw that 2005 Express did not have a SQL Agent.

Thanks for the response.

Does Replication Agent locks the database?

Hi,
Does the first synchronization(Replication Agent) while setting up merge
replication locks both the publisher and subscriber databases or the
databases can be used while the first synchronization is taking place?
If first synchronization does not lock the databases, will the changes that
have taken place at both the ends be merged later on, when synchronization
is complete?
Thanks
Anukul
Anukul,
there is no exclusive lock on the database, if that is what you are
referring to. There is a shared lock on the database as there would be on
any connection. As far as I know, there aren't exclusive locks held on the
table during the snapshot generation in merge replication. There are
page-level shared locks which'll prevent updates while the snapshot of a
particular page is being generated, but concurrent reads are compatible. In
transactional there is the option to use concurrent snapshot processing
where concurrent changes can occur during the snapshot generation, but not
so in merge or snapshot replication.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul:
I am talking about Replication Agent, which runs after snapshot agent.
Replication Agnet does the syncronization.
Please suggest.
Thanks,
Anukul
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:OLV3bsFGFHA.3888@.TK2MSFTNGP12.phx.gbl...
> Anukul,
> there is no exclusive lock on the database, if that is what you are
> referring to. There is a shared lock on the database as there would be on
> any connection. As far as I know, there aren't exclusive locks held on the
> table during the snapshot generation in merge replication. There are
> page-level shared locks which'll prevent updates while the snapshot of a
> particular page is being generated, but concurrent reads are compatible.
In
> transactional there is the option to use concurrent snapshot processing
> where concurrent changes can occur during the snapshot generation, but not
> so in merge or snapshot replication.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||My understanding is that the merge agent works with
batches of records and each separate batch is treated as
a transaction, but the combined synchronization process
is not held under a global transaction. In this case, an
edit to a record on a batch already processed would be
acceptable and would enter MSmerge_contents.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Documentation of RMO and Merge Replication

Hi there,

In a lot of the Replication documentation it only refers to the merge agent operating in the context of a push or a pull configuration. i.e. if it is push then the merge agent is at the distributor but if it is a pull then the merge agent functions at the subscriber.

I recently joined a project which is configured as a push but it uses RMO for synchronisation. This RMO application is installed on a compeletely separate server. Initially I thought the RMO was just passing requests through to the publisher/distributor/subscriber but the distributor didn't seem to be doing any of the work. It therefore seems that the merging/synchronisation is being performed on this RMO application server and not the distributor or subscriber.

I therefore think it would be good (assuming I am correct of course) that the documentation reflects this caveat

As a general observation Replication programming seems to be quite detached from the rest of the replication documentation. Is this a deliberate decision?

It isn't normally, but I'll ping the writer in charge of this and ask.

Buck Woody

|||

To answer your last question first. Yes, it was a product-wide design decision to put all of the programming API documentation for SQL Server together in a separate node. I agree with you that it isn't ideal. In the next release of SQL Server, we will include the programming content for each component with the rest of the component's conceptual content.

There is no general requirement that an RMO application run on a replication server. SQL Server Management Studio (SSMS) uses RMO to perform administrative tasks in replication, and you can administer replication on remote servers using SSMS. You can also synchronize subscriptions remotely using RMO (MergeSubscription.SynchronizeWithJob in the case of a push subscription), which runs the agent job on the Distributor to asynchronously start the Merge Agent. To run the Merge Agent synchronously (MergeSynchronizationAgent.Synchronize) and receive callbacks (synchronization status events), your application needs to run on the same server as the Merge Agent (the Distributor in your case).

I will see if we can make the RMO documentation more clear on this point.

Best wishes,

Glenn Gailey [MSFT]

SQL Server UE

|||

Hi Glenn & Buck,

Thanks very much for getting back to me.

I am glad to hear that the API docs will be more integrated in katmai.

On the other point I am a little confused. In our setup the merge application using RMO runs on a totally separate server to the distributor but this third machine (distributor is remote to the publisher) has SQL Express installed. We get back all the callbacks and replication is operating. I mention this because I think this kind of setup isn't really referred to in BOL but I also believe it is a permissable setup (although not perhaps a very common one).

Cheers, James

|||Is your RMO application running on the Subscriber server, or on a 4th server totally outside the Pub/Dist/Sub topology?|||

It sits on a completely separate 4th server.

Cheers, James

|||

I checked with the development team, and it is possible to run the Merge Agent remotely (both synchronously and asynchronously) using RMO. I will look into providing this information in the documentation.

Cheers!

|||Is it possible to run application that uses RMO on a server without installing SQL server? From the posts in this thread I assume the 4th server has SQLServer Express 2005 installation just to be able to run RMO app.|||

That is correct. You do need to have at least sql express installed. This is the only way to get the RMO components onto the server.

Cheers, James

Documentation of RMO and Merge Replication

Hi there,

In a lot of the Replication documentation it only refers to the merge agent operating in the context of a push or a pull configuration. i.e. if it is push then the merge agent is at the distributor but if it is a pull then the merge agent functions at the subscriber.

I recently joined a project which is configured as a push but it uses RMO for synchronisation. This RMO application is installed on a compeletely separate server. Initially I thought the RMO was just passing requests through to the publisher/distributor/subscriber but the distributor didn't seem to be doing any of the work. It therefore seems that the merging/synchronisation is being performed on this RMO application server and not the distributor or subscriber.

I therefore think it would be good (assuming I am correct of course) that the documentation reflects this caveat

As a general observation Replication programming seems to be quite detached from the rest of the replication documentation. Is this a deliberate decision?

It isn't normally, but I'll ping the writer in charge of this and ask.

Buck Woody

|||

To answer your last question first. Yes, it was a product-wide design decision to put all of the programming API documentation for SQL Server together in a separate node. I agree with you that it isn't ideal. In the next release of SQL Server, we will include the programming content for each component with the rest of the component's conceptual content.

There is no general requirement that an RMO application run on a replication server. SQL Server Management Studio (SSMS) uses RMO to perform administrative tasks in replication, and you can administer replication on remote servers using SSMS. You can also synchronize subscriptions remotely using RMO (MergeSubscription.SynchronizeWithJob in the case of a push subscription), which runs the agent job on the Distributor to asynchronously start the Merge Agent. To run the Merge Agent synchronously (MergeSynchronizationAgent.Synchronize) and receive callbacks (synchronization status events), your application needs to run on the same server as the Merge Agent (the Distributor in your case).

I will see if we can make the RMO documentation more clear on this point.

Best wishes,

Glenn Gailey [MSFT]

SQL Server UE

|||

Hi Glenn & Buck,

Thanks very much for getting back to me.

I am glad to hear that the API docs will be more integrated in katmai.

On the other point I am a little confused. In our setup the merge application using RMO runs on a totally separate server to the distributor but this third machine (distributor is remote to the publisher) has SQL Express installed. We get back all the callbacks and replication is operating. I mention this because I think this kind of setup isn't really referred to in BOL but I also believe it is a permissable setup (although not perhaps a very common one).

Cheers, James

|||Is your RMO application running on the Subscriber server, or on a 4th server totally outside the Pub/Dist/Sub topology?|||

It sits on a completely separate 4th server.

Cheers, James

|||

I checked with the development team, and it is possible to run the Merge Agent remotely (both synchronously and asynchronously) using RMO. I will look into providing this information in the documentation.

Cheers!

|||Is it possible to run application that uses RMO on a server without installing SQL server? From the posts in this thread I assume the 4th server has SQLServer Express 2005 installation just to be able to run RMO app.
|||

That is correct. You do need to have at least sql express installed. This is the only way to get the RMO components onto the server.

Cheers, James