Merge Agent/

If i want to inquire about the outstand transactions before i sync. what kind
of info can i pull out form the merge agent/or where to get this info..say i
want to know how many deletes did i do in this replica before i decide to
sync...
is that possible programatically?
You can't, but you could query the publisher and subscriber for the number
of transactions at the max generation. You would query the tombstone and
contents tables to get this number.
Hilary
"Lottoman2000 NEWBE" <Lottoman2000NEWBE@.discussions.microsoft.com> wrote in
message news:1047463C-6853-499F-A879-B40FC4E648E4@.microsoft.com...
> If i want to inquire about the outstand transactions before i sync. what
> kind
> of info can i pull out form the merge agent/or where to get this info..say
> i
> want to know how many deletes did i do in this replica before i decide to
> sync...
> is that possible programatically?
>
|||Have a look at the procedure spBrowseMergeChanges on this page:
http://www.replicationanswers.com/Merge.asp
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Memory leak when using ReportViewer control

If you create a form with nothing other than the ReportViewer control on it,
then open that form from another form and close it, about 50K appears to be
used each time. If you run an actual report in the control, then the memory
increases in relation to the size of the report. I have a report that when
run consumes about 130MB of memory. When I close the form, the memory usage
in my app only drops to about 80MB. If I then open the form again and run
the report again, the memory usage jumps up to over 170MB and when the form
is closed it drops back down to about 130MB. These numbers change depending
on the report you run and the amount of data and number of controls on the
report, but there is a definite leak when using the ReportViewer control.
Other people have seen the leak as well:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=449474&SiteID=1
I can not find an answer anywhere, someone at Microsoft really needs to
adress this issue.
Thank you!
BrianI wonder if it is a true leak. Memory management under dotnet can be quite
delayed.
I am using the control as well (winform), I'll do some looking into this.
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Brian Adams" <BrianAdams@.discussions.microsoft.com> wrote in message
news:1A9A0F7D-5BDF-491F-9851-2B48EEF6C244@.microsoft.com...
> If you create a form with nothing other than the ReportViewer control on
> it,
> then open that form from another form and close it, about 50K appears to
> be
> used each time. If you run an actual report in the control, then the
> memory
> increases in relation to the size of the report. I have a report that
> when
> run consumes about 130MB of memory. When I close the form, the memory
> usage
> in my app only drops to about 80MB. If I then open the form again and run
> the report again, the memory usage jumps up to over 170MB and when the
> form
> is closed it drops back down to about 130MB. These numbers change
> depending
> on the report you run and the amount of data and number of controls on the
> report, but there is a definite leak when using the ReportViewer control.
> Other people have seen the leak as well:
> http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=449474&SiteID=1
> I can not find an answer anywhere, someone at Microsoft really needs to
> adress this issue.
> Thank you!
> Brian
>|||Thanks Bruce. I even went so far as to call System.GC.Collect() and
System.GC.WaitForPendingFinalizers() to ensure the garbage collector ran and
memory was being cleaned up. It didn't have any effect on the results I was
seeing.
I had no references to the form left, and no references to any of the
objects the form referenced, so the calls to Collect should have been able to
clean up all memory because there were no remaining references to any of the
instantiated objects. The reports were all RDLC (client side) based, so
everything was completely disconnected and isolated to the form itself. When
it went away, so should have all the memory that was allocated during its
lifetime. Unless there is some caching going on in the runtime I'm not aware
of. If this were the case, I would have expected the memory usage to level
off at some point, but it seemed to continue climbing each time I created the
form/ran report/closed form. These results were based on initial Task
Manager observations, and then perfmon monitoring.
"Bruce L-C [MVP]" wrote:
> I wonder if it is a true leak. Memory management under dotnet can be quite
> delayed.
> I am using the control as well (winform), I'll do some looking into this.
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Brian Adams" <BrianAdams@.discussions.microsoft.com> wrote in message
> news:1A9A0F7D-5BDF-491F-9851-2B48EEF6C244@.microsoft.com...
> > If you create a form with nothing other than the ReportViewer control on
> > it,
> > then open that form from another form and close it, about 50K appears to
> > be
> > used each time. If you run an actual report in the control, then the
> > memory
> > increases in relation to the size of the report. I have a report that
> > when
> > run consumes about 130MB of memory. When I close the form, the memory
> > usage
> > in my app only drops to about 80MB. If I then open the form again and run
> > the report again, the memory usage jumps up to over 170MB and when the
> > form
> > is closed it drops back down to about 130MB. These numbers change
> > depending
> > on the report you run and the amount of data and number of controls on the
> > report, but there is a definite leak when using the ReportViewer control.
> >
> > Other people have seen the leak as well:
> > http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=449474&SiteID=1
> >
> > I can not find an answer anywhere, someone at Microsoft really needs to
> > adress this issue.
> >
> > Thank you!
> > Brian
> >
>
>