messageText:
A call to the ProcessInput method for input 507 on component "CNT RowsInput" (505) unexpectedly kept a reference to the buffer it was passed. The refcount on that buffer was 4 before the call, and 5 after the call returned.
dataCode: -2147192599
dataBytes:
The CNT RowsInput transformation is right between the oledb source and the derive transformation. It is the 2nd transformation in the data flow.
I use all defaults for the Data flow task and provide a valid BufferTempStoragePath.
The closest/detailed explaination I found
A call to the ProcessInput method for input %1!d! on %2!s! unexpectedly kept a reference to the buffer it was passed. The refcount on that buffer was %3!d! before the call, and %4!d! after the call returned. The component is keeping references to buffers it shouldn't. If it needs to keep the buffer, it should make a copy of the buffer for itself by calling the Clone method.
fromhttp://wiki.sqlis.com/default.aspx/SQLISWiki/0x800470E9.html
Hi Tianyu
Did you find an answer on this?
I am getting exactly the same problem with a custom row count component I have written - I'm keen to find out the cause.
Thanks . . . Ed
|||Hi, Allen
We don't have any answer to this yet. Last time I researched still nothing on it :(
Tianyu
|||I randomly get that same warning on different components... and its on fairly "simple" standard components (multicast is the most common one to get that error for me, followed by rowcount)|||Tianyu / Chris
See this thread - http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=705702&SiteID=1
Regards . . . Ed
|||Yeah, I saw that... I figured it didn't really matter - but it doesn't help me much when I have a script in my Master package that looks for any warnings from any of the many packages the Master runs, compiles all the warnings and sends it to me and my boss. He of course in turn asks what is wrong and when I say not to worry about the buffer error he wants to know why he gets emails on it then.... LOL I haven't actually found an instance where the rowcount was wrong after one of those warnings.
Mailing all the warnings and errors has saved our butts - for example when someone changed a table that is used for lookups it caused the lookup to match multiple records we got a warning. So I highly recommend the practice but its kinda lame becuase people have started to ignore the warnings when about 50% of the time at least one of the daily packages will get that error about the buffers.
|||I found this warning too. Do I need to do something or just leave it?|||Tom, I'd say to just ignore it after spot checking your results a few times. In my package which emails warnings and errors I added code to explicitly ignore that error. In the hundreds of packages run everyday we've never had this warning result in incorrect data.
No comments:
Post a Comment