Report saving physical database path instead of ODBC location in CR9

[GMcNamara]

I am trying to run a report (that I developed in 8.5) in Crystal 9. I am running into problems refreshing the report because the physical database path instead of the ODBC location has been saved with the report. So, rather than connecting to ODBC and logging me onto the database that I have specified, it is following the physical database path and logging me onto the database that was saved with the report in 8.5.
I can go to Set DataSource Location and change the physical path to the ODBC and the report runs as I would like. However, I am converting over 100 reports and I think there has to be an easier way. Have I configured a setting wrong? Thanks for your time.

 

[TedLiu]

I assume you are using CR8.5 but not CE8.5. In CR8.5, you always can dynamically changed the data source in runtime, which is not possible in CE8.5. for example, you can use setLogoninfo to change the data source in asp page. That means Back-end database is not important since you can change it in runtime.

Hope it helps.

Ted

 

[GMcNamara]

Thanks for your reply. However, I don't think this will solve my problem.
First, let me say that I am simply opening Crystal and running these reports. I am not distributing the reports on the web, through VB, or ASP.
OK, in CR 8.5, when I refreshed the report, it would go to my ODBC, check where it was pointing, log me on to that database, the report would run, and all was fine. Now, in CR 9, when I refresh the report, it goes to the physical path that it saved with the report from the last time it was run, logs me on to that database (regardless of where my ODBC is pointing), and the report uses data from the old database. Also, when I check my ODBC, it has been changed by the report to the location from the physical path that it had saved from the last time the report was saved. YES, it actually changes the ODBC configuration.
I don't know if that made sense so allow me to give a quick example.
I created a report in CR 8.5. My ODBC is pointed to database_A. I save the report in 8.5. Then, I change the ODBC to database_B. I open the report in CR 9 and click refresh. The login box logs me into database_A. When I check the ODBC, it is once again pointing to database_A.
I can use the Set Location feature to make the DSN point where I want and most of the time it works. However, I have many, many, many reports that are used by many clients. Using this 'work-around' is not a viable option.

 

[TedLiu]

GM,

I understand your situation even I'm still no sure how you implement them. As I said, if you build the program no matter what it is, VB, ASP or whatever, you have the way to do the job by code. If only by open Crystal Designer and preview the report, then Set location is the only way to know the database change as I know. That may become time consuming if you have tons of reports.

I forget how exactly SetLogonInfo works. I'm not quite sure whether it can change the datasource or not, if it does, maybe just develop a small program to change all the report datasource to new one.


Ted

 

[ellemae]

I could not tell if you had already done this, but I assume you have went and directly changed the ODBC data source from the control panel/ODBC options and saved that change. When you go in through Crystal reports and changed the database location, it does not change the permanent pointer for your ODBC connection. That must be done separately. I have done this a few times without problems so make sure you are changing the ODBC in the control panel and not just within database/set location in Crystal. You shouldn't even have to do this if you change that database location in ODBC. Hope this helps!

 

[GMcNamara]

I agree with everything you said. That was exactly my thinking until I started using Crystal 9. I am creating and saving the report in CR 8.5. Then, after I have closed the report, I am changing the ODBC data source through the control panel/ODBC options. THEN, when I open and refresh the report in CR 9, the fun starts. I am not changing the database location in Crystal. It is taking the physical database path that it saved with the report in 8.5, and connecting to that database, regardless of where my ODBC is pointing. As a matter of fact, it doesn't matter where my ODBC was pointing because refreshing the report is changing the permanent pointer to my ODBC connection.
I have contacted Crystal support and am scheduled to have a 'support session' with them tomorrow. I will post the findings.

 

[befine]

This is a (long) link to a posting on the microsoft.public.vb.crystal newsgroup that I think deals with the same issue you've addressed here. Apparently, CR9 will not let you point to a different database/serverlocation.

http://groups.google.com/groups?dq=...r=&ie=UTF-8&group=microsoft.public.vb.crystal

 

[GMcNamara]

I just finished my support session with Crystal support. Once the Support Tech saw that the report was logging on to the saved database and the report was actually changing the ODBC pointer, he said, "Oh my god. That is a problem". So, hopefully a fix will be coming soon.

 

[GMcNamara]

I want to bump this to the top because I have not received any resolution from Crystal support. Has anyone else experienced this, and if so, what have you done to solve this? Please let me know if you have seen this so I know that I am not crazy.

I just can't believe that you can't develop a report and then distribute it to someone else, so they can run the report USING THEIR OWN DATABASE. We are desperate for a solution. Thank you.

 

[Reebo99]

I can believe it.....In Crystal Enterprise it gives you the option the change the database location via Crystal Management Console.

It sounds like the sort of thing Crystal have been doing recently to try to push people onto Crystal Enterprise. Although V9 adds some well needed functionality such as SQL Command and formula output limitation removed, the fact that you can no longer compile reports in V9 is bloody annoying. Crystal's official response is you don't need to compile reports anymore cause you can use the Report Application Server for Report Delivery.



Reebo
UK

 

[GMcNamara]

This is not sound business thinking on Crystal's part. We have a custom application that we run our reports through. We can't simply convert to CE because our app has a lot more (and different) functionality than Crystal Enterprise. This kind of business strategy will cause us and I assume many others to convert to a different reporting application.

 

[FVTrainer]

There is something about your issue that I don't understand. I have never deployed an app that doesn't use some method for changing the report datasource location (such as SetTableLocation or SetLogOnInfo). Are you deploying the report in an application and remaining solely dependent on the odbc connection to provide connectivity? (There is not a criticism built into that question, I just want to make sure I understand your issue correctly.)

 

[GMcNamara]

We are running a Delphi application. We were calling the LogonServer method of the Application object. As I said, this worked with 8.5 because it looked to the ODBC DSN to find the db connection information. There was no need to muck with the db connection because we wanted it to point to the ODBC. In 9, it follows the actual path to the database that was saved in the report.

Anyway, I finally spoke with someone at Crystal who was able to solve the issue. We are now using the ConnectionProperties object of the Table object. By calling the DeleteAll method, we are throwing out all of the saved information. Then we use the Add method to reset the connection information, user name, etc. This call is made for the first table and propagates through every table of the report. The only remaining issue involves each subreport needing it's own db connection but I suspect that will be resolved in short order.

 

[gquint]

Hello GMcNamara,
Like you we are running a Delphi application as well. With Delphi I created a viewer-app for both CR8.5 and CR9 reports. With CR9 I have the same problem: I can't re-route to another database. May I ask what integration method do you use? Because I can't find the ConnectionProperties of the Table-object. I use the VCL-component (UCrpe32.pas).

 

[rnd]

We also ran into the same problem. I reported this matter as a bug but the CD (before merge with BO) guys counted that incident against me and provided the same solution that I already knew - ie. Individually update each table. Though CE9 allows you to change the ODBC name outside or inside the underlying properties originally created at design time don't change.
The good news is the path is immaterial when you run the report through an application (we also use a custom application). The log-in credentials should supercede the built in credentials. The main difference between 8.5 and 9 is you should, in your application, also provide the Database Name in addition to the DSN, UserId, and Password for the Crystal interface part.
As regards passing the same credentials to the sub reports, the recent sp and hotfixes have taken care of that problem. You may have to download them. As long as the application, Crystal main and sub reports are using the same DSN and Database you won't get the popup windows.