Showing posts with label subscriber. Show all posts
Showing posts with label subscriber. Show all posts

Wednesday, March 21, 2012

Didn't show part of rows at subscriber

Dear all,
I'm confuse knowing that some rows didn't replicated to subscriber. No error, no message, no idea at all.
Is there any workaround to do? I'm not sure to have resnapshot because of the large data and long distance site.
I'm using simple merge replication. No filter or any modified things.
Pls help.
TIA
Echo,
I've seen this in 2 circumstances. Firstly when the filter was set to 1=2
and inserts were made while the merge agent was running and secondly when a
bulk insert was carried out without firing the triggers.
To fix the extra rows that haven't been replicated, there are 2 different
procedures (details in BOL):
SP_MERGEDUMMYUPDATE
SP_ADDTABLETOCONTENTS
HTH,
Paul Ibison
|||>Firstly when the filter was set to 1=2 and inserts were made while the merge agent was running
- I don't have any idea. No filter at all.
>secondly when a bulk insert was carried out without firing the triggers
- Do you mean the triggers those made by replication? why didn't they fire?
Still don't know how to use sp_mergedummyupdate or sp_addtabletocontents.
What to fill in the parameters?
Thanks a lot Paul
"Paul Ibison" wrote:

> Echo,
> I've seen this in 2 circumstances. Firstly when the filter was set to 1=2
> and inserts were made while the merge agent was running and secondly when a
> bulk insert was carried out without firing the triggers.
> To fix the extra rows that haven't been replicated, there are 2 different
> procedures (details in BOL):
> SP_MERGEDUMMYUPDATE
> SP_ADDTABLETOCONTENTS
> HTH,
> Paul Ibison
>
>
|||Echo,
The triggers I was referring to are the replication triggers. On an insert,
a record should be entered into MSmerge_contents and this is done using a
trigger. The trigger won't fire on a bulk insert (by default).
The dummy update takes 2 arguments - the tablename and the guid of the row
which didn't replicate and works for single
rows(http://msdn.microsoft.com/library/de...y/en-us/tsqlre
f/ts_sp_repl3_7r6t.asp).
Sp_addtabletocontents will do this work for an entire table
(http://msdn.microsoft.com/library/de...-us/tsqlref/ts
_sp_repl_05wz.asp) and just has the table and owner as arguments.
In each case, doing the synchronization afterwards is necessary.
HTH,
Paul Ibison

Friday, February 17, 2012

Determining when to send the report based on information inside the report?!?

Hello

Here is a tricky problem to which I didn't find any "good" solution:

I have a report which should be sent to the subscriber only when there is something to report. Mostly the report will be empty, because it will only report emergency-type-of-stuff. Now I have implemented the report logic twice, once in the report and once in a data driven subscription which returns a fixed email address when the report data query returns data.

Ideal solution would be one where you can decide in the report generation is it sent or not. Has anyone any ideas / solutions conserning this problem? How could you decide during the report generation that is report sent or not? Any help is highly appreciated...

Thanks!

- rusi

Well, that seems a bit interesting...one problem I see is that the report generation could be performed anytime...i.e. on a schedule, or also anytime a user interactivelly requests to view the report. So, if for example you did include logic to email the report anytime the report generation included data, would you want to get multiple emails time after time if a user kept viewing the report every 10-15 minutes or something like that?

Seems to me that your best bet would be to encapsulate the data-portion of the report (i.e. the queries/data sets) within a stored procedure that you can call from multiple places, and if the sp returns any results, fire off an email from your automated systems when you would like under controlled circumstances.

As it is, I'm not entirely sure that you can even fire off an email based on report content...maybe someone else can chime in on this part...

|||Thanks for the answer!
That is true that the report is ran every time, in this case twice a day, and it sends a report of orders that have not been confirmed. But there is no need to send the report if there are no unconfirmed orders eg. nothing to report...
It is possible to solve this putting the logic in one sp, but still have to implement to logic somewhere else then in the report. I'm searching for the best solution in which the report includes all the logic.
|||This is a fairly common request. Your current solution is the best work around that we have right now. We are looking at the possibility of adding this feature in future versions.