cancel
Showing results for 
Search instead for 
Did you mean: 

Link from ASP.NET Crystal Report loses GET variables. 3-year old documented bug--any fix?

Former Member
0 Kudos

I have a report that I migrated from Crystal Server 2008 to 2011. One part of the report generates a link to an external ASP.NET application, passing along the appropriate variables to that application via GET. On both servers in the appropriate Crystal Report application (2008 or 2011) the report works and generates a link correctly. Accessing the report from through the ASP.NET application is a different story, however.

Here are the links created by the report in each version, which I'm getting by right-clicking and choosing "copy link" in Chrome:

2008: http://www.host.com/intranet/API_PriceInc_Ltr/Start.aspx?slmno=1001&cusno=18301&venno=15&cutoff=08/0...

2011: parent.bobj.event.publish('hyperlinkClicked','CrystalReportViewer1__UI','target=_self&url=%2fintranet%2fAPI_PriceInc_Ltr%2fStart.aspx%3fslmno%3d1001%26cusno%3d1830 1%26venno%3d15%26cutoff%3d08%2f01%2f2013%26increase%3d1%26shipaddr%3d77486%26effective%3d08%2f30%2f2013%26slmname%3dXXX')

Now, if I feed the URL from the 2011 version into a URL decoder, I get this: target=_self&url=/intranet/API_PriceInc_Ltr/Start.aspx?slmno=1001&cusno=18301&venno=15&cutoff=08/01/2013&increase=1&shipaddr=77486&effective=08/30/2013&slmname=xxx

The above URL string is correct and does work when I go to the address. Unfortunately when I click on the link, what I get instead is this:

/intranet/API_PriceInc_Ltr/Start.aspx?slmno

As you can see, all the variables are simply missing.

This isn't a problem caused by the new server as far as I can tell. It seems instead to be an issue with the way bobj is processing the link in the 2011 version. Since the get parameters are simply not appearing after the link is clicked, I'm not sure how to resolve this.

Any suggestions?

Edit: I found documentation that this is a bug, though no actual fix was posted. Here is an earlier thread discussing this issue: http://scn.sap.com/message/9553393

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member183750
Active Contributor
0 Kudos

The issue according to the associated ADAPT (ADAPT01481748 ) was resolved in SP 1 for "SAP Crystal Reports, developer version for Microsoft Visual Studio". The Discussion you reference was re. "SAP Crystal Reports, developer version for Microsoft Visual Studio" only and there was no mention of CR Server 2008, CR Server 2011 or CR 2008.

So, from here, I need to know the actual version of the CR assemblies referenced in your web app.

- Ludek

Senior Support Engineer AGS Product Support, Global Support Center Canada

Follow us on Twitter

Got Enhancement ideas? Try the SAP Idea Place

Share Your Knowledge in SCN Topic Spaces

Former Member
0 Kudos

Ludek,

Sure. The file version of CrystalDecisions.CrystalReports.Engine is 14.0.4.738 and the version is 14.0.3500.0. The other files match. For the Crystal Reports for Visual Studio version, I'm using CRforVS_13_0_6.

former_member183750
Active Contributor
0 Kudos

Ok, good, but still need more clarity (sorry).

File version 14.x is from BI 4.x

File version 13.x is from "SAP Crystal Reports, developer version for Microsoft Visual Studio"

You can not mix the two in the same app. Thus in your app, what version of assemblies are you referencing?

Also, please let me know the verisno of the crpe32.dll in this directory:

C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86

- Ludek

Former Member
0 Kudos

They're all 14.x--I ran into issues with that in an earlier version of the application and came across a post you'd made saying they don't mix, so I was careful about that.

The file version for crpe32.dll in that location is 13.0.6.1027. This is the same both on my machine (where I'm compiling the code from) and on the web server. I'm not sure if the BI 4.X installation occurred after I had installed 13.x and didn't replace the older copy correctly or if there's some other reason for this. If there's a 14.x version I can replace that with, I'd be happy to try that.

former_member183750
Active Contributor
0 Kudos

Hi Ben

Since the assemblies are version 14.x, then the app should be using crpe32.dll of version 14.x also. That one will be in this folder:

C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win32_x86

A side by side install of version 13 and version 14 is ok - the two will never talk to each other.

- Ludek

Former Member
0 Kudos

Gotcha--and yes, the file in that location is 14.x.

Any ideas on a solution to the problem? Have you been able to replicate it?

Former Member
0 Kudos

Any news on this, Ludek?

former_member183750
Active Contributor
0 Kudos

Yup

I did two very simple tests. One using version 13 assemblies and one using version 14 assemblies. I used the attached rpt (unzip, rename to .rpt). The code was as simple as you can get:

 

Private Sub CrystalReportViewer1_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles CrystalReportViewer1.Init    

CrystalReportViewer1.ReportSource = "C:\Tests\ADAPT01481748\reportWithHyperlink.rpt"

End Sub

Can you pls try the attached report in your app?

- Ludek

Former Member
0 Kudos

I created a test document with that page and ran it. Here is the link generated with v14:

javascript:parent.bobj.event.publish('hyperlinkClicked','CrystalReportViewer1__UI','target=_self&url=http%3a%2f%2fwww.msn.com%2f%3fst%3d1')

Clicking on it takes me to this URL: http://www.msn.com/?st

The =1 is being lost in translation.

I tried opening it in a v13 project since you weren't explicit on whether you wanted me to do one or both, but that simply gives me this:

Error
Load report failed.

There are no errors either in VS2012 or in the browser, so I was not able to determine the source of this problem.

former_member183750
Active Contributor
0 Kudos

Load report error indicates that the path to the report is incorrect. It honestly is the only time you will get the error. Please check that the path you are loading the report from is correct. Also make sure the %TEMP% directory has read / write permissions as the engine needs to write to it.

- Ludek

Former Member
0 Kudos

I'm not sure what caused it, but exiting VS2012 and then re-opening the project did it. The path was fine since I added it to the root directory of the site (same folder as Default.aspx) and then accessed it via this:

    protected void Page_Load(object sender, EventArgs e)

    {

        CrystalReportViewer1.ReportSource = "testReport.rpt";

    }

I can confirm that in v13 it works fine. Here is the generated link in v13:

javascript:parent.bobj.event.publish('hyperlinkClicked','CrystalReportViewer1__UI','target=_self&url=http%253a%252f%252fwww.msn.com%252f%253fst%253d1')

And here is where it takes me:

http://www.msn.com/?st=1

Comparing the v13 to the v14 links (using what I posted earlier), the only difference is in the url string as follows:

v13 url=http%3a%2f%2fwww.msn.com%2f%3fst%3d1

v14 url=http%253a%252f%252fwww.msn.com%252f%253fst%253d1

former_member183750
Active Contributor
0 Kudos

Can you share the report you are testing with? (It will need saved data). Or are you using the report I attached?

- Ludek

Former Member
0 Kudos

That's from the report you attached.

former_member183750
Active Contributor
0 Kudos

OK. Ben, noting that you are using VS 2012, are you running the app from the .NET IDE (using cassini as the web browser) or are you using IIS when running this project?

- Ludek

former_member183750
Active Contributor
0 Kudos

And one more thing. I note in your code:

CrystalReportViewer1.ReportSource = "testReport.rpt";

I attached a report called reportWithHyperlink.rpt, not testReport.rpt. Did you rename the report?

And, you should have a path to the report. Something like:

CrystalReportViewer1.ReportSource = "@c:\folder where I have the report\testReport.rpt";

- Ludek

Former Member
0 Kudos

I am using IIS. Specifically I have the page hosted on Server 2008 R2.

Former Member
0 Kudos

testReport.rpt was another report I created as a quick test when I was having the issue I described above with the Load Report Failed error. Once I restarted VS2012 both reports (testReport.rpt and the reportWithHyperlink.rpt you provided) would open and worked correctly with v13 

As for this:

CrystalReportViewer1.ReportSource = "testReport.rpt";

I put the test report into the local directory, so there is no need for an absolute path to the file. The report files open fine, the issue is with the links generated by the v14 environment.

former_member183750
Active Contributor
0 Kudos

Huh? I don't think you are correct. Try to add the full path.

- Ludek

Former Member
0 Kudos

I assure you, the report loads fine with relative pathing. You may want to verify it on your end, but I've been using it with no problems both in the test application we're discussing here (using the above code) and in other implementations. It's much more convenient to use relative pathing.

At your request I've used absolute pathing as well, but it made no difference either in the loading of the report (it works fine either way) nor in the link not working properly in a v14 environment.

Former Member
0 Kudos

Ludek,

Any news on this?

former_member183750
Active Contributor
0 Kudos

Hello Ben

I have nothing to add as I know this works for me here. You may want to consider using Process Monitor and see what it tells you about the rpt files being loaded.

- Ludek

Former Member
0 Kudos

Well, the rpt you sent is giving me the same issue, so I don't see the reports themselves being the issue. Do you have the same setup I'm in? .NET 4.0, Server 2008 R2, 64bit? It seems like the installation or environment have to be the problem since the example report is identical, but I'm not sure where this could be coming in. With it matching exactly the bug I linked in the original post, it seems likely that the Crystal Server installation is at fault, but I'm not sure why I would have the problem but you would not.

former_member183750
Active Contributor
0 Kudos

ProcMon will be a really good idea.

- Ludek