Re-initializing an anonymous subscription from the server - error

Hi,

I'm trying to force an anonymous subscription to re-intialize on it's next sync attempt. I can do this from the subscriber no problems, and from the publisher using 'Re-initalize All Subscriptions', but I can't seem to re-intialize only a single subscription from the publisher.

To do this I'm trying to execute sp_reinitmergesubscription using the subscriber details found in the sysmergesubscriptions table. This executes ok and when the subscriber starts to sync it does try to re-initialize starting with generating a new snapshot, but after processing for a while it throws the following error messages:

Error messages:
The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

There doesn't appear to be any shortage of memory on the server. There is no problem regenerating the snapshot from the publisher, and there's no problem with syncing through the web using delta syncs or re-initializing from the subscriber, so I can't see any obvious cause from those error messages.

I'm using SQL Server 2005 SP2 on the publisher, and SQL ServerCE 3.1 on the subscriber.

Any ideas or alternatives?

Cheers

With an anonymous subscription the publisher is unable to connect to the subsciber so I would guess that actions like forcing a re-init cannot be done from the publisher.

Your root message is saying that the process could not deliver the snapshot to the subscriber. It is trying to connect to the subscriber but cannot as it is anonymous.

Martin

|||Thanks for the response.

I thought that SQL Server 2005 was supposed to remove a lot of the limitations of anonymous subscribers. In this case, as the subscriber can receive the snapshot when the re-init is initiated on the subscriber, I don't understand why it can't receive it when intiated on the publisher. The client obviously recognises that a re-init is required, surely from then the process should be the same?

Any other ideas?
|||

Has anybody successfully forced an anonymous subscriber to re-initiliaze from the publisher? I would have thought this was a fairly common requirement.

|||

Are you using push or pull subscription? If you are using push, can you try to use pull instead and see if that would work for you?

Regards,
Gary

|||

I'm using a pull subscription. As far as I know, SQL Server CE only supports anonymous pull subscriptions.

I've since been advised from a support engineer (via MSC) that SQL Server 2005 can't re-initialise anonymous subscribers from the publisher, only from the subscriber. I can't see why this limitation would be in place, but it is consistent with the errors I'm getting.

The workaround will be to build into the application a pre-sync check which connects to the publisher and checks a re-init flag, then re-inits from the subscriber based on that flag.

If anyone else can suggest an alterantive (or challenge the assertion that anonymous subscriptions can't be re-init from the publisher) I'm keen to hear it.

Thanks

|||

Steve, you should be able to reinitialize your mobile subscriber from the publisher.

exec pubdb..sp_reinitmergesubscription '<PublicationName>', @.subscriber='mysubscriber - aaaaaaaaaaaa', @.subscriber_db='D:\myPathToMobileDatabase.sdf'

I got the subscriber and subscriber_db from the publisher server's sysmergesubscriptions.

I executed the above at the publisher and the subscriber upon next sync was able to reinitialize.

Let me know if you are not seeing this and I would be interested to find out what issue you are encountering.

Note that I tried this on a desktop installation of mobile.

|||

I am using the same process. I grabbed the details out of the sysmergesubscriptions table and then executed the sp_reinitmergesubscription procedure. When the subscriber starts to sync, it recognises that a re-init is necessary and begins that process. If an up-to-date snapshot is not available it generates one otherwise it immediatly starts to transfer the data. At this point it stops with the following error messages:

The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

The set up I'm using is SQL Server 2005 on Windows Server 2003 and SQL CE 3.1 on Windows XP (ie not mobile). The desktop is our target setup (although most clients are on Windows 2000).

I've also tried doing this in different combinations ie with both the SQL CE and the SQL Server 2005 databases on the Windows 2003 server, and with both running on the win xp desktop, but all get the same errors. In none of these situations is re-initialising from the subscriber an issue.

Any ideas on how to progress this?

|||

Further testing has uncovered an interesting way to get this work. For some reason if I validate all subscribers after using sp_reinitmergesubscription to re-intialise a single subscriber, the subscriber syncs and reinitialises fine. This is obviously not ideal, as forcing all subscribers to validate creates unnecassary overhead, but the result is that I don't get errors from the subscriber re-initialisation.

So my current steps are:

exec sp_reinitmergesubscription

kick off the dynamic snapshot job for the subscriber

exec sp_validatemergepublication

Re-initializing an anonymous subscription from the server - error

Hi,

I'm trying to force an anonymous subscription to re-intialize on it's next sync attempt. I can do this from the subscriber no problems, and from the publisher using 'Re-initalize All Subscriptions', but I can't seem to re-intialize only a single subscription from the publisher.

To do this I'm trying to execute sp_reinitmergesubscription using the subscriber details found in the sysmergesubscriptions table. This executes ok and when the subscriber starts to sync it does try to re-initialize starting with generating a new snapshot, but after processing for a while it throws the following error messages:

Error messages:
The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

There doesn't appear to be any shortage of memory on the server. There is no problem regenerating the snapshot from the publisher, and there's no problem with syncing through the web using delta syncs or re-initializing from the subscriber, so I can't see any obvious cause from those error messages.

I'm using SQL Server 2005 SP2 on the publisher, and SQL ServerCE 3.1 on the subscriber.

Any ideas or alternatives?

Cheers

With an anonymous subscription the publisher is unable to connect to the subsciber so I would guess that actions like forcing a re-init cannot be done from the publisher.

Your root message is saying that the process could not deliver the snapshot to the subscriber. It is trying to connect to the subscriber but cannot as it is anonymous.

Martin

|||Thanks for the response.

I thought that SQL Server 2005 was supposed to remove a lot of the limitations of anonymous subscribers. In this case, as the subscriber can receive the snapshot when the re-init is initiated on the subscriber, I don't understand why it can't receive it when intiated on the publisher. The client obviously recognises that a re-init is required, surely from then the process should be the same?

Any other ideas?
|||

Has anybody successfully forced an anonymous subscriber to re-initiliaze from the publisher? I would have thought this was a fairly common requirement.

|||

Are you using push or pull subscription? If you are using push, can you try to use pull instead and see if that would work for you?

Regards,
Gary

|||

I'm using a pull subscription. As far as I know, SQL Server CE only supports anonymous pull subscriptions.

I've since been advised from a support engineer (via MSC) that SQL Server 2005 can't re-initialise anonymous subscribers from the publisher, only from the subscriber. I can't see why this limitation would be in place, but it is consistent with the errors I'm getting.

The workaround will be to build into the application a pre-sync check which connects to the publisher and checks a re-init flag, then re-inits from the subscriber based on that flag.

If anyone else can suggest an alterantive (or challenge the assertion that anonymous subscriptions can't be re-init from the publisher) I'm keen to hear it.

Thanks

|||

Steve, you should be able to reinitialize your mobile subscriber from the publisher.

exec pubdb..sp_reinitmergesubscription '<PublicationName>', @.subscriber='mysubscriber - aaaaaaaaaaaa', @.subscriber_db='D:\myPathToMobileDatabase.sdf'

I got the subscriber and subscriber_db from the publisher server's sysmergesubscriptions.

I executed the above at the publisher and the subscriber upon next sync was able to reinitialize.

Let me know if you are not seeing this and I would be interested to find out what issue you are encountering.

Note that I tried this on a desktop installation of mobile.

|||

I am using the same process. I grabbed the details out of the sysmergesubscriptions table and then executed the sp_reinitmergesubscription procedure. When the subscriber starts to sync, it recognises that a re-init is necessary and begins that process. If an up-to-date snapshot is not available it generates one otherwise it immediatly starts to transfer the data. At this point it stops with the following error messages:

The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

The set up I'm using is SQL Server 2005 on Windows Server 2003 and SQL CE 3.1 on Windows XP (ie not mobile). The desktop is our target setup (although most clients are on Windows 2000).

I've also tried doing this in different combinations ie with both the SQL CE and the SQL Server 2005 databases on the Windows 2003 server, and with both running on the win xp desktop, but all get the same errors. In none of these situations is re-initialising from the subscriber an issue.

Any ideas on how to progress this?

|||

Further testing has uncovered an interesting way to get this work. For some reason if I validate all subscribers after using sp_reinitmergesubscription to re-intialise a single subscriber, the subscriber syncs and reinitialises fine. This is obviously not ideal, as forcing all subscribers to validate creates unnecassary overhead, but the result is that I don't get errors from the subscriber re-initialisation.

So my current steps are:

exec sp_reinitmergesubscription

kick off the dynamic snapshot job for the subscriber

exec sp_validatemergepublication

Re-initializing an anonymous subscription from the server - error

Hi,

I'm trying to force an anonymous subscription to re-intialize on it's next sync attempt. I can do this from the subscriber no problems, and from the publisher using 'Re-initalize All Subscriptions', but I can't seem to re-intialize only a single subscription from the publisher.

To do this I'm trying to execute sp_reinitmergesubscription using the subscriber details found in the sysmergesubscriptions table. This executes ok and when the subscriber starts to sync it does try to re-initialize starting with generating a new snapshot, but after processing for a while it throws the following error messages:

Error messages:
The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

There doesn't appear to be any shortage of memory on the server. There is no problem regenerating the snapshot from the publisher, and there's no problem with syncing through the web using delta syncs or re-initializing from the subscriber, so I can't see any obvious cause from those error messages.

I'm using SQL Server 2005 SP2 on the publisher, and SQL ServerCE 3.1 on the subscriber.

Any ideas or alternatives?

Cheers

With an anonymous subscription the publisher is unable to connect to the subsciber so I would guess that actions like forcing a re-init cannot be done from the publisher.

Your root message is saying that the process could not deliver the snapshot to the subscriber. It is trying to connect to the subscriber but cannot as it is anonymous.

Martin

|||Thanks for the response.

I thought that SQL Server 2005 was supposed to remove a lot of the limitations of anonymous subscribers. In this case, as the subscriber can receive the snapshot when the re-init is initiated on the subscriber, I don't understand why it can't receive it when intiated on the publisher. The client obviously recognises that a re-init is required, surely from then the process should be the same?

Any other ideas?
|||

Has anybody successfully forced an anonymous subscriber to re-initiliaze from the publisher? I would have thought this was a fairly common requirement.

|||

Are you using push or pull subscription? If you are using push, can you try to use pull instead and see if that would work for you?

Regards,
Gary

|||

I'm using a pull subscription. As far as I know, SQL Server CE only supports anonymous pull subscriptions.

I've since been advised from a support engineer (via MSC) that SQL Server 2005 can't re-initialise anonymous subscribers from the publisher, only from the subscriber. I can't see why this limitation would be in place, but it is consistent with the errors I'm getting.

The workaround will be to build into the application a pre-sync check which connects to the publisher and checks a re-init flag, then re-inits from the subscriber based on that flag.

If anyone else can suggest an alterantive (or challenge the assertion that anonymous subscriptions can't be re-init from the publisher) I'm keen to hear it.

Thanks

|||

Steve, you should be able to reinitialize your mobile subscriber from the publisher.

exec pubdb..sp_reinitmergesubscription '<PublicationName>', @.subscriber='mysubscriber - aaaaaaaaaaaa', @.subscriber_db='D:\myPathToMobileDatabase.sdf'

I got the subscriber and subscriber_db from the publisher server's sysmergesubscriptions.

I executed the above at the publisher and the subscriber upon next sync was able to reinitialize.

Let me know if you are not seeing this and I would be interested to find out what issue you are encountering.

Note that I tried this on a desktop installation of mobile.

|||

I am using the same process. I grabbed the details out of the sysmergesubscriptions table and then executed the sp_reinitmergesubscription procedure. When the subscriber starts to sync, it recognises that a re-init is necessary and begins that process. If an up-to-date snapshot is not available it generates one otherwise it immediatly starts to transfer the data. At this point it stops with the following error messages:

The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

The set up I'm using is SQL Server 2005 on Windows Server 2003 and SQL CE 3.1 on Windows XP (ie not mobile). The desktop is our target setup (although most clients are on Windows 2000).

I've also tried doing this in different combinations ie with both the SQL CE and the SQL Server 2005 databases on the Windows 2003 server, and with both running on the win xp desktop, but all get the same errors. In none of these situations is re-initialising from the subscriber an issue.

Any ideas on how to progress this?

|||

Further testing has uncovered an interesting way to get this work. For some reason if I validate all subscribers after using sp_reinitmergesubscription to re-intialise a single subscriber, the subscriber syncs and reinitialises fine. This is obviously not ideal, as forcing all subscribers to validate creates unnecassary overhead, but the result is that I don't get errors from the subscriber re-initialisation.

So my current steps are:

exec sp_reinitmergesubscription

kick off the dynamic snapshot job for the subscriber

exec sp_validatemergepublication

Re-initializing an anonymous subscription from the server - error

Hi,

I'm trying to force an anonymous subscription to re-intialize on it's next sync attempt. I can do this from the subscriber no problems, and from the publisher using 'Re-initalize All Subscriptions', but I can't seem to re-intialize only a single subscription from the publisher.

To do this I'm trying to execute sp_reinitmergesubscription using the subscriber details found in the sysmergesubscriptions table. This executes ok and when the subscriber starts to sync it does try to re-initialize starting with generating a new snapshot, but after processing for a while it throws the following error messages:

Error messages:
The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

There doesn't appear to be any shortage of memory on the server. There is no problem regenerating the snapshot from the publisher, and there's no problem with syncing through the web using delta syncs or re-initializing from the subscriber, so I can't see any obvious cause from those error messages.

I'm using SQL Server 2005 SP2 on the publisher, and SQL ServerCE 3.1 on the subscriber.

Any ideas or alternatives?

Cheers

With an anonymous subscription the publisher is unable to connect to the subsciber so I would guess that actions like forcing a re-init cannot be done from the publisher.

Your root message is saying that the process could not deliver the snapshot to the subscriber. It is trying to connect to the subscriber but cannot as it is anonymous.

Martin

|||Thanks for the response.

I thought that SQL Server 2005 was supposed to remove a lot of the limitations of anonymous subscribers. In this case, as the subscriber can receive the snapshot when the re-init is initiated on the subscriber, I don't understand why it can't receive it when intiated on the publisher. The client obviously recognises that a re-init is required, surely from then the process should be the same?

Any other ideas?
|||

Has anybody successfully forced an anonymous subscriber to re-initiliaze from the publisher? I would have thought this was a fairly common requirement.

|||

Are you using push or pull subscription? If you are using push, can you try to use pull instead and see if that would work for you?

Regards,
Gary

|||

I'm using a pull subscription. As far as I know, SQL Server CE only supports anonymous pull subscriptions.

I've since been advised from a support engineer (via MSC) that SQL Server 2005 can't re-initialise anonymous subscribers from the publisher, only from the subscriber. I can't see why this limitation would be in place, but it is consistent with the errors I'm getting.

The workaround will be to build into the application a pre-sync check which connects to the publisher and checks a re-init flag, then re-inits from the subscriber based on that flag.

If anyone else can suggest an alterantive (or challenge the assertion that anonymous subscriptions can't be re-init from the publisher) I'm keen to hear it.

Thanks

|||

Steve, you should be able to reinitialize your mobile subscriber from the publisher.

exec pubdb..sp_reinitmergesubscription '<PublicationName>', @.subscriber='mysubscriber - aaaaaaaaaaaa', @.subscriber_db='D:\myPathToMobileDatabase.sdf'

I got the subscriber and subscriber_db from the publisher server's sysmergesubscriptions.

I executed the above at the publisher and the subscriber upon next sync was able to reinitialize.

Let me know if you are not seeing this and I would be interested to find out what issue you are encountering.

Note that I tried this on a desktop installation of mobile.

|||

I am using the same process. I grabbed the details out of the sysmergesubscriptions table and then executed the sp_reinitmergesubscription procedure. When the subscriber starts to sync, it recognises that a re-init is necessary and begins that process. If an up-to-date snapshot is not available it generates one otherwise it immediatly starts to transfer the data. At this point it stops with the following error messages:

The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

The set up I'm using is SQL Server 2005 on Windows Server 2003 and SQL CE 3.1 on Windows XP (ie not mobile). The desktop is our target setup (although most clients are on Windows 2000).

I've also tried doing this in different combinations ie with both the SQL CE and the SQL Server 2005 databases on the Windows 2003 server, and with both running on the win xp desktop, but all get the same errors. In none of these situations is re-initialising from the subscriber an issue.

Any ideas on how to progress this?

|||

Further testing has uncovered an interesting way to get this work. For some reason if I validate all subscribers after using sp_reinitmergesubscription to re-intialise a single subscriber, the subscriber syncs and reinitialises fine. This is obviously not ideal, as forcing all subscribers to validate creates unnecassary overhead, but the result is that I don't get errors from the subscriber re-initialisation.

So my current steps are:

exec sp_reinitmergesubscription

kick off the dynamic snapshot job for the subscriber

exec sp_validatemergepublication

Re-initializing an anonymous subscription from the server - error

Hi,

I'm trying to force an anonymous subscription to re-intialize on it's next sync attempt. I can do this from the subscriber no problems, and from the publisher using 'Re-initalize All Subscriptions', but I can't seem to re-intialize only a single subscription from the publisher.

To do this I'm trying to execute sp_reinitmergesubscription using the subscriber details found in the sysmergesubscriptions table. This executes ok and when the subscriber starts to sync it does try to re-initialize starting with generating a new snapshot, but after processing for a while it throws the following error messages:

Error messages:
The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

There doesn't appear to be any shortage of memory on the server. There is no problem regenerating the snapshot from the publisher, and there's no problem with syncing through the web using delta syncs or re-initializing from the subscriber, so I can't see any obvious cause from those error messages.

I'm using SQL Server 2005 SP2 on the publisher, and SQL ServerCE 3.1 on the subscriber.

Any ideas or alternatives?

Cheers

With an anonymous subscription the publisher is unable to connect to the subsciber so I would guess that actions like forcing a re-init cannot be done from the publisher.

Your root message is saying that the process could not deliver the snapshot to the subscriber. It is trying to connect to the subscriber but cannot as it is anonymous.

Martin

|||Thanks for the response.

I thought that SQL Server 2005 was supposed to remove a lot of the limitations of anonymous subscribers. In this case, as the subscriber can receive the snapshot when the re-init is initiated on the subscriber, I don't understand why it can't receive it when intiated on the publisher. The client obviously recognises that a re-init is required, surely from then the process should be the same?

Any other ideas?
|||

Has anybody successfully forced an anonymous subscriber to re-initiliaze from the publisher? I would have thought this was a fairly common requirement.

|||

Are you using push or pull subscription? If you are using push, can you try to use pull instead and see if that would work for you?

Regards,
Gary

|||

I'm using a pull subscription. As far as I know, SQL Server CE only supports anonymous pull subscriptions.

I've since been advised from a support engineer (via MSC) that SQL Server 2005 can't re-initialise anonymous subscribers from the publisher, only from the subscriber. I can't see why this limitation would be in place, but it is consistent with the errors I'm getting.

The workaround will be to build into the application a pre-sync check which connects to the publisher and checks a re-init flag, then re-inits from the subscriber based on that flag.

If anyone else can suggest an alterantive (or challenge the assertion that anonymous subscriptions can't be re-init from the publisher) I'm keen to hear it.

Thanks

|||

Steve, you should be able to reinitialize your mobile subscriber from the publisher.

exec pubdb..sp_reinitmergesubscription '<PublicationName>', @.subscriber='mysubscriber - aaaaaaaaaaaa', @.subscriber_db='D:\myPathToMobileDatabase.sdf'

I got the subscriber and subscriber_db from the publisher server's sysmergesubscriptions.

I executed the above at the publisher and the subscriber upon next sync was able to reinitialize.

Let me know if you are not seeing this and I would be interested to find out what issue you are encountering.

Note that I tried this on a desktop installation of mobile.

|||

I am using the same process. I grabbed the details out of the sysmergesubscriptions table and then executed the sp_reinitmergesubscription procedure. When the subscriber starts to sync, it recognises that a re-init is necessary and begins that process. If an up-to-date snapshot is not available it generates one otherwise it immediatly starts to transfer the data. At this point it stops with the following error messages:

The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

The set up I'm using is SQL Server 2005 on Windows Server 2003 and SQL CE 3.1 on Windows XP (ie not mobile). The desktop is our target setup (although most clients are on Windows 2000).

I've also tried doing this in different combinations ie with both the SQL CE and the SQL Server 2005 databases on the Windows 2003 server, and with both running on the win xp desktop, but all get the same errors. In none of these situations is re-initialising from the subscriber an issue.

Any ideas on how to progress this?

|||

Further testing has uncovered an interesting way to get this work. For some reason if I validate all subscribers after using sp_reinitmergesubscription to re-intialise a single subscriber, the subscriber syncs and reinitialises fine. This is obviously not ideal, as forcing all subscribers to validate creates unnecassary overhead, but the result is that I don't get errors from the subscriber re-initialisation.

So my current steps are:

exec sp_reinitmergesubscription

kick off the dynamic snapshot job for the subscriber

exec sp_validatemergepublication

Re-initializing an anonymous subscription from the server - error

Hi,

I'm trying to force an anonymous subscription to re-intialize on it's next sync attempt. I can do this from the subscriber no problems, and from the publisher using 'Re-initalize All Subscriptions', but I can't seem to re-intialize only a single subscription from the publisher.

To do this I'm trying to execute sp_reinitmergesubscription using the subscriber details found in the sysmergesubscriptions table. This executes ok and when the subscriber starts to sync it does try to re-initialize starting with generating a new snapshot, but after processing for a while it throws the following error messages:

Error messages:
The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

There doesn't appear to be any shortage of memory on the server. There is no problem regenerating the snapshot from the publisher, and there's no problem with syncing through the web using delta syncs or re-initializing from the subscriber, so I can't see any obvious cause from those error messages.

I'm using SQL Server 2005 SP2 on the publisher, and SQL ServerCE 3.1 on the subscriber.

Any ideas or alternatives?

Cheers

With an anonymous subscription the publisher is unable to connect to the subsciber so I would guess that actions like forcing a re-init cannot be done from the publisher.

Your root message is saying that the process could not deliver the snapshot to the subscriber. It is trying to connect to the subscriber but cannot as it is anonymous.

Martin

|||Thanks for the response.

I thought that SQL Server 2005 was supposed to remove a lot of the limitations of anonymous subscribers. In this case, as the subscriber can receive the snapshot when the re-init is initiated on the subscriber, I don't understand why it can't receive it when intiated on the publisher. The client obviously recognises that a re-init is required, surely from then the process should be the same?

Any other ideas?
|||

Has anybody successfully forced an anonymous subscriber to re-initiliaze from the publisher? I would have thought this was a fairly common requirement.

|||

Are you using push or pull subscription? If you are using push, can you try to use pull instead and see if that would work for you?

Regards,
Gary

|||

I'm using a pull subscription. As far as I know, SQL Server CE only supports anonymous pull subscriptions.

I've since been advised from a support engineer (via MSC) that SQL Server 2005 can't re-initialise anonymous subscribers from the publisher, only from the subscriber. I can't see why this limitation would be in place, but it is consistent with the errors I'm getting.

The workaround will be to build into the application a pre-sync check which connects to the publisher and checks a re-init flag, then re-inits from the subscriber based on that flag.

If anyone else can suggest an alterantive (or challenge the assertion that anonymous subscriptions can't be re-init from the publisher) I'm keen to hear it.

Thanks

|||

Steve, you should be able to reinitialize your mobile subscriber from the publisher.

exec pubdb..sp_reinitmergesubscription '<PublicationName>', @.subscriber='mysubscriber - aaaaaaaaaaaa', @.subscriber_db='D:\myPathToMobileDatabase.sdf'

I got the subscriber and subscriber_db from the publisher server's sysmergesubscriptions.

I executed the above at the publisher and the subscriber upon next sync was able to reinitialize.

Let me know if you are not seeing this and I would be interested to find out what issue you are encountering.

Note that I tried this on a desktop installation of mobile.

|||

I am using the same process. I grabbed the details out of the sysmergesubscriptions table and then executed the sp_reinitmergesubscription procedure. When the subscriber starts to sync, it recognises that a re-init is necessary and begins that process. If an up-to-date snapshot is not available it generates one otherwise it immediatly starts to transfer the data. At this point it stops with the following error messages:

The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

The set up I'm using is SQL Server 2005 on Windows Server 2003 and SQL CE 3.1 on Windows XP (ie not mobile). The desktop is our target setup (although most clients are on Windows 2000).

I've also tried doing this in different combinations ie with both the SQL CE and the SQL Server 2005 databases on the Windows 2003 server, and with both running on the win xp desktop, but all get the same errors. In none of these situations is re-initialising from the subscriber an issue.

Any ideas on how to progress this?

|||

Further testing has uncovered an interesting way to get this work. For some reason if I validate all subscribers after using sp_reinitmergesubscription to re-intialise a single subscriber, the subscriber syncs and reinitialises fine. This is obviously not ideal, as forcing all subscribers to validate creates unnecassary overhead, but the result is that I don't get errors from the subscriber re-initialisation.

So my current steps are:

exec sp_reinitmergesubscription

kick off the dynamic snapshot job for the subscriber

exec sp_validatemergepublication

Re-initializing an anonymous subscription from the server - error

Hi,

I'm trying to force an anonymous subscription to re-intialize on it's next sync attempt. I can do this from the subscriber no problems, and from the publisher using 'Re-initalize All Subscriptions', but I can't seem to re-intialize only a single subscription from the publisher.

To do this I'm trying to execute sp_reinitmergesubscription using the subscriber details found in the sysmergesubscriptions table. This executes ok and when the subscriber starts to sync it does try to re-initialize starting with generating a new snapshot, but after processing for a while it throws the following error messages:

Error messages:
The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

There doesn't appear to be any shortage of memory on the server. There is no problem regenerating the snapshot from the publisher, and there's no problem with syncing through the web using delta syncs or re-initializing from the subscriber, so I can't see any obvious cause from those error messages.

I'm using SQL Server 2005 SP2 on the publisher, and SQL ServerCE 3.1 on the subscriber.

Any ideas or alternatives?

Cheers

With an anonymous subscription the publisher is unable to connect to the subsciber so I would guess that actions like forcing a re-init cannot be done from the publisher.

Your root message is saying that the process could not deliver the snapshot to the subscriber. It is trying to connect to the subscriber but cannot as it is anonymous.

Martin

|||Thanks for the response.

I thought that SQL Server 2005 was supposed to remove a lot of the limitations of anonymous subscribers. In this case, as the subscriber can receive the snapshot when the re-init is initiated on the subscriber, I don't understand why it can't receive it when intiated on the publisher. The client obviously recognises that a re-init is required, surely from then the process should be the same?

Any other ideas?
|||

Has anybody successfully forced an anonymous subscriber to re-initiliaze from the publisher? I would have thought this was a fairly common requirement.

|||

Are you using push or pull subscription? If you are using push, can you try to use pull instead and see if that would work for you?

Regards,
Gary

|||

I'm using a pull subscription. As far as I know, SQL Server CE only supports anonymous pull subscriptions.

I've since been advised from a support engineer (via MSC) that SQL Server 2005 can't re-initialise anonymous subscribers from the publisher, only from the subscriber. I can't see why this limitation would be in place, but it is consistent with the errors I'm getting.

The workaround will be to build into the application a pre-sync check which connects to the publisher and checks a re-init flag, then re-inits from the subscriber based on that flag.

If anyone else can suggest an alterantive (or challenge the assertion that anonymous subscriptions can't be re-init from the publisher) I'm keen to hear it.

Thanks

|||

Steve, you should be able to reinitialize your mobile subscriber from the publisher.

exec pubdb..sp_reinitmergesubscription '<PublicationName>', @.subscriber='mysubscriber - aaaaaaaaaaaa', @.subscriber_db='D:\myPathToMobileDatabase.sdf'

I got the subscriber and subscriber_db from the publisher server's sysmergesubscriptions.

I executed the above at the publisher and the subscriber upon next sync was able to reinitialize.

Let me know if you are not seeing this and I would be interested to find out what issue you are encountering.

Note that I tried this on a desktop installation of mobile.

|||

I am using the same process. I grabbed the details out of the sysmergesubscriptions table and then executed the sp_reinitmergesubscription procedure. When the subscriber starts to sync, it recognises that a re-init is necessary and begins that process. If an up-to-date snapshot is not available it generates one otherwise it immediatly starts to transfer the data. At this point it stops with the following error messages:

The merge process could not allocate memory for an operation; your system may be running low on virtual memory. Restart the Merge Agent. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147198720)
Get help: http://help/MSSQL_REPL-2147198720
An error occurred while reading the .bcp data file for the 'CDP_TableDates' article. If the .bcp file is corrupt, you must regenerate the snapshot before initializing the Subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199428)
Get help: http://help/MSSQL_REPL-2147199428
The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have been unable to create or write to the message file. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)

The set up I'm using is SQL Server 2005 on Windows Server 2003 and SQL CE 3.1 on Windows XP (ie not mobile). The desktop is our target setup (although most clients are on Windows 2000).

I've also tried doing this in different combinations ie with both the SQL CE and the SQL Server 2005 databases on the Windows 2003 server, and with both running on the win xp desktop, but all get the same errors. In none of these situations is re-initialising from the subscriber an issue.

Any ideas on how to progress this?

|||

Further testing has uncovered an interesting way to get this work. For some reason if I validate all subscribers after using sp_reinitmergesubscription to re-intialise a single subscriber, the subscriber syncs and reinitialises fine. This is obviously not ideal, as forcing all subscribers to validate creates unnecassary overhead, but the result is that I don't get errors from the subscriber re-initialisation.

So my current steps are:

exec sp_reinitmergesubscription

kick off the dynamic snapshot job for the subscriber

exec sp_validatemergepublication

Re-indexing table causes Windows to re-boot !

I have a DB with multiple tables and when I attempt to index one of the
tables the whole Windows servers crashes and reboots. My understanding is
that SQLServer should run as an isolated application and so should not be
able to affect the operating system.
This server has been fine for over a year now but has just started to
exhibit this problem (no recent changes or updates to the server, apart from
regular anti-virus updates, that could account for this behaviour).
The problem in more detail:
Database - 1577MB data (518 MB free). Set to automatically grow at 10% to
an un-restricted limit (data and log)
Table in question - 900808 KB data, ~7000000 rows of data
Indexes - there are three "user" indexes that I create. One of them is a
clustered index. When any of these indexes is built the server crashes.
Exhaustive DBCC tests imply that the DB and table are in perfect health.
Nothing in the event log and no memory dumps.
SQLServer - SQLServer 2000 sp3a
Windows - Win2000 sp3, IBM XSERIES_335 with 3 GHz xeon processor and oodles
of memory.
User - at wits end
Any advice would be most welcome
Thanks
GriffGriff,
You are correct. You should focus on the operating system. Most likely SQL
Server is just taxing the IO or Processor hard and there is either a
hardware or driver issue. In the event log is it an unexpected reboot or is
there a stop error listed?
"Griff" <Howling@.The.Moon> wrote in message
news:%234bILC2vFHA.2556@.TK2MSFTNGP15.phx.gbl...
>I have a DB with multiple tables and when I attempt to index one of the
>tables the whole Windows servers crashes and reboots. My understanding is
>that SQLServer should run as an isolated application and so should not be
>able to affect the operating system.
> This server has been fine for over a year now but has just started to
> exhibit this problem (no recent changes or updates to the server, apart
> from regular anti-virus updates, that could account for this behaviour).
> The problem in more detail:
> Database - 1577MB data (518 MB free). Set to automatically grow at 10% to
> an un-restricted limit (data and log)
> Table in question - 900808 KB data, ~7000000 rows of data
> Indexes - there are three "user" indexes that I create. One of them is a
> clustered index. When any of these indexes is built the server crashes.
> Exhaustive DBCC tests imply that the DB and table are in perfect health.
> Nothing in the event log and no memory dumps.
> SQLServer - SQLServer 2000 sp3a
> Windows - Win2000 sp3, IBM XSERIES_335 with 3 GHz xeon processor and
> oodles of memory.
> User - at wits end
> Any advice would be most welcome
> Thanks
> Griff
>
>|||Having read the event logs (application, system, security & SQLServer
ones) and searched for a memory dmp file I get the impression that the
server crashed so fast that it simply didn't have the chance to log
anything. Metaphorically speaking, it had the rug pulled from under
it.
The event log simply lists the fact that it rebooted after an
unexpected system shutdown, but I can't find anything that implies what
could have caused the system shutdown.
Watching the task manager whilst the re-indexing is occuring (before it
dies), it shows no real sign of taxing the server's resources. Of
course now, running live without indexes, the server is as slow as a
lame dog, presumably because SQLServer is having to do lots of full
table scans.|||Oddly enough I've seen this scenerio with two of our 32 way servers. We and
the hardware vendor were able to reproduce the system fault but the vendor
never could tell us what was wrong or how to fix it. Basically when the
server approached 100% CPU (doing masive qeries) the system started geting
dirty memory transfers between pods. It all started after we upgraded our
SQL Server 2000 build. We switched to 64 bit HP servers and immediately
stopped experiencing the issue. Assuming a good power supply, in my opinion
any unexpected reboot on a Windows server is one of three things.
From most likely to least likely:
1. A hardware issue
2. A poorly written driver in kernal mode
3. Windows not trapping the error.
SQL Server may be pushing the system in a new way or to 100% but that would
be a performance issue not an availability issue.
Good luck.
"Griff" <griffithsj_520@.hotmail.com> wrote in message
news:1127390278.062254.254300@.g49g2000cwa.googlegroups.com...
> Having read the event logs (application, system, security & SQLServer
> ones) and searched for a memory dmp file I get the impression that the
> server crashed so fast that it simply didn't have the chance to log
> anything. Metaphorically speaking, it had the rug pulled from under
> it.
> The event log simply lists the fact that it rebooted after an
> unexpected system shutdown, but I can't find anything that implies what
> could have caused the system shutdown.
> Watching the task manager whilst the re-indexing is occuring (before it
> dies), it shows no real sign of taxing the server's resources. Of
> course now, running live without indexes, the server is as slow as a
> lame dog, presumably because SQLServer is having to do lots of full
> table scans.
>|||Well, I can't say what the problem was, but we do appear to have fixed it.
Despite nothing "appearing" to have changed on the system (we manually apply
the Microsoft critical upgrades), this problem started occuring out of the
blue.
However, it got worse throughout the day - the server started rebooting
during "normal" use, approximately ever 30 minutes. As mentioned
previously, the CPU was more or less at 100% because we couldn't rebuild the
indexes, so I was wondering whether it could be overheating or some other
symptom of the hardware being over-stressed (though it's a good spec server
so should cope).
Anyhow, that evening we clutched at straws and applied Win2000 sp4 (had been
sp3) and, would you believe it, it fixed the problem and a good nights sleep
was had by all.|||Griff wrote:
> Well, I can't say what the problem was, but we do appear to have
> fixed it.
> Despite nothing "appearing" to have changed on the system (we
> manually apply the Microsoft critical upgrades), this problem started
> occuring out of the blue.
> However, it got worse throughout the day - the server started
> rebooting during "normal" use, approximately ever 30 minutes. As
> mentioned previously, the CPU was more or less at 100% because we
> couldn't rebuild the indexes, so I was wondering whether it could be
> overheating or some other symptom of the hardware being over-stressed
> (though it's a good spec server so should cope).
> Anyhow, that evening we clutched at straws and applied Win2000 sp4
> (had been sp3) and, would you believe it, it fixed the problem and a
> good nights sleep was had by all.
Probably someone was "joking": there are some holes in some windows
versions which allow a host to be restarted / switched off or similar via
network (these are usually closed by sp4 IIRC). So it could even be
manual intervention that caused this...
Kind regards
robert|||Hi Robert
I believe that we can almost rule that one out. The server is behind a
firewall that only allows HTTP in from unknown IP addresses, everything else
is effectively blocked. The only person who can connect to it in any other
way is me.
But hey, we know that the only way to make a computer completely safe is to
switch it off.