Invalid analyzer handle

Discussions related to Crystal Reports development.

Moderator: Lisa Ennis

Post Reply
ckootg
Posts: 116
Joined: Fri Jan 06, 2012 6:10 pm

Invalid analyzer handle

Post by ckootg » Wed Sep 23, 2015 5:36 pm

After upgrading from 4.0.30302.58 to 4.0.30302.62, we have seen "Invalid analyzer handle" errors when running some reports in SoftPro. Other similar reports run fine. The reports run fine in Visual Studio or Crystal Reports application.

When I grabbed one of the *.conf.rpt file from the temp directory and ran it, this particular report reported a "A number is required here." error. The field was BuyerName and there was formula checking for an empty string ({BuyerName} = "")

Lisa Ennis
Posts: 81
Joined: Thu Sep 11, 2008 1:57 pm

Re: Invalid analyzer handle

Post by Lisa Ennis » Thu Sep 24, 2015 9:22 am

The first step I would do in troubleshooting this issue would be to open the report in Crystal Reports and verify the database. This can assist with identifying issues with fields being returned by your query. Also, if your report is using a stored procedure, does the stored procedure execute on the database outside of the report?
Lisa Ennis
Report Developer
SoftPro

ckootg
Posts: 116
Joined: Fri Jan 06, 2012 6:10 pm

Re: Invalid analyzer handle

Post by ckootg » Thu Sep 24, 2015 5:05 pm

The problem was a stored procedure change. We are using SoftPro's rptdoc.BuyerSellerSideBySideByCDFId and for some reason, your developers decided to remove the #SideBySide temp table in SoftPro version 4.0.30302.62, that clearly defines the field types for the select return. The rptdoc.BuyerSellerSideBySideByHUDId stored procedure still uses the #SideBySide temp table. Quite honestly, I don't think it's SoftPro's fault....Crystal Report should have be able to derive the field types correctly on it's own.

Lisa Ennis
Posts: 81
Joined: Thu Sep 11, 2008 1:57 pm

Re: Invalid analyzer handle

Post by Lisa Ennis » Thu Sep 24, 2015 5:37 pm

That specific stored procedure had been troublesome on a customer's site due to how a join was being handled by SQL and rendered unexpected results, causing it to break the document. We split the sub report that was returning both buyers and sellers side by side into separate sub reports. The new sub reports are named "SP_Hud_Attachment_BuyerHeading_ByHUDId_Sub.rpt" and SP_Hud_Attachment_SellerHeading_ByHUDId_Sub.rpt and are used on the Attachment page of the 1986 and 2009 HUD's and other related documents.
Lisa Ennis
Report Developer
SoftPro

Post Reply