[RESOLVED]Problems with ReportViewer, ScriptManager, and ICallbackEventHandler

I am having problems porting a screen from 32 bit (SQL 2005, WinServer 2003, IIS 6) to 64 bit (SQL 2008, WinServer 2008, IIS 7.5).  This screen uses BOTH iCallBackEventHandler and a Reportviewer object, and works fine on the old server.  (I also had to add
a ScriptManager object which was not needed before.)

On the new server, when I issue a SetParameters call, it kills the ICallBackEventHandler interface.  All I have to do is comment out that line, and the program works (but parameters have to be set manually).  Enable it, and my client browser will no longer
receive any events sent through the ICallBackEventHandler interface.

Is there any fix for this?  Any way to see what is going on?  Or did we paint ourselves into a corner by using MS products before their architecture was refined enough (I imagine it’s going to be a while before we go 128 bit OS)?

Due to the way the report viewer uses script, it is currently not compatible with an UpdatePanel.  Microsoft is aware of this problem and looking into the necessary changes to get the ReportViewer working in an UpdatePanel.  But at present, there is no work
around.  While it may appear you can get simple reports working in this scenario, some of the more subtle report viewer behavior will still be broken, such as its code that keeps the report session alive when the browser window is left open.

http://forums.asp.net/p/1044194/3436555.aspx

http://forums.asp.net/p/1340895/2713548.aspx

It means I have to rewrite the product in a system that can handle the ‘complexity’, and I’m dead in the water with my current SQL 2005 implementation – I doubt that MS is worried because they already sold their product to us, and if software we developed
4 years ago is now unexpectedly useless, that’s our fault for making bad decisions.  But thanks for the reply, Chetan.

Leave a Reply