Bizarre Settings!

[Turkbear]

Hi,
If you have changed the Datasource and fail to reset it, why would you expect it not to fail when republished?

The ODBC datasource configuration specified by your change must also exist on the CE server..If not it can only fail.
( Or have I misunderstood what you describe as happening?)

 

[NattyCat]

Hi Turkbear,

The reports are deployed to versions of Crystal Enterprise on all the environments. So, the users use the Production environment, where they have a list of reports that they can run via the web interface of Crystal Enterprise.

The reports are packaged up and deployed to all the environments and they work fine. The problem is that if we develop the reports in Crystal Reports, when we physically save that report, we have to make sure it is pointed to test 1/reports before it is deployed even though the reports are deployed to all of the other environments. So for example, on the livrep01 server, they have a report which we will call "Monthly Sales".

I wrote this report using the test01/reports server data. I then sent it over to the person who uploads it into Crystal Enterprise, and he deploys it into every Enterprise Environment.

Because I saved the datasource as testsql01/reports, Crystal Enterprise, somehow, knows to change this setting to each respective environment it is deployed to. If, however, i'd accidently saved the report while it was pointing to, say, uatsql01/reports, when it is deployed, Crystal Enterprise doesn't seem to be able to automatically change the setting from the saved server name in the report to the server name the report is being deployed to.

Does this make sense?

 

[NattyCat]

I develop reports in Crystal 9 or 10
I use Crystal Enterprise 10
against SQL Server 7 databases

Due to the implementation of the first phase of our project, we have several environments that we develop/work in. We have sql databases entitled Test 1, Test 2, UAT, Pre-Production, Production, Test 1/Reports, Test 2/Reports, UAT/Reports etc. We run log-shipping and DTS against these environments pretty much hourly to synchronise the data.

Most of the reports developed for this project are pointed at test 1 as it has reasonable data. However, we can, at any time, point our reports to any of the other environments which will return different data which can be useful when fault-fixing.

One thing we have found, which I can only describe as "Bizarre" is the fact that no matter which database we choose to develop our reports in, be it test 1/reports, test 2/reports, uat/reports - the report MUST be set to Test 1/reports when it is saved and deployed.

If we develop the report in test 1/reports and then, using "Database|Set Datasource Location" to point it at production or any other environment (just as a part of testing etc) and we forget to put it back to test 1/reports - when the report is deployed into Crystal Enterprise, it fails.

Has anyone else found this?

This has been a mild irritant up until now, with the massive workloads we have on we sometimes forget to point the database back to test 1/reports before we deploy it and when the user runs the report it fails with an ODBC error. Deployments only happen twice a week so this fault could cause the fix of a report to take over a week to be returned back to the user.

The even bigger problem that is facing us now, is that I've just heard that they are removing the test 1 environment. This issue is now going to be very serious as we won't be able to point any reports at test 1/reports any more, so all 300+ reports will fail.

If anyone can shed any light on this problem, please let me know!

Natasha

 

[Turkbear]

Hi,
How would it 'know' to do this..It just saves what you give it. ( Its not smart enough to make decisions as to what should be, just what is, and besides, you would not want it to change what you tell it to do)

Just how many CE environments do you have ( given the cost, why have lots? - the advantage of CE is centralization of Web access to Reports)


Maybe I'm still missing something?

 

[NattyCat]

We use a CRM system, called Onyx. We have Test SQL databases, Live databases, UAT databases and Development databases. Each database is kept synchronised with log shipping and dts services. We also have test, development, production (live) and UAT versions of the Onyx CRM screens.

The user logs into Onyx on the production server. Within their CRM screen it says "reports". They click on this link and it opens the folder list in Crystal Enterprise. They go to their relevant folder, choose their report and run it.

Because they are running this report from the production screen, the database that the report uses is livrep01/reports. If a developer opened up a copy of the Onyx CRM screen in the UAT environment for example, the reports would run from uatsql01/reports.

This all works fine but ONLY if the developer who wrote the report saves the report with the "database|set datasource location" pointed to testsql01/reports.

This is what I mean by "knows how". Depending on which environment the reports are run from Crystal uses the corresponding database.

If the developer has, whilst fixing/testing/developing the report set the datasource location to, say, uatsql01/reports and whilst in a rush, forgets to go to database|set datasource location and change it back to testsql01/reports before he uploads it to Enterprise, the report will fail in all screens.

So in the production CRM screen, the user will click reports, go to their folder, run their report and it will return an ODBC error because, when the report was saved, it wasn't set to testsql01/reports.

 

[pelajhia]

This makes no sense, you are right.

When the reports are uploaded, does the admin then configure the database settings to point to the production database? (in the cmc goto process>database screen)
(eg - all reports are uploaded pointing to test, but then are repointed once published to production (otherwise they retrieve test data, right?))

 

[NattyCat]

yes, thats exactly right.

 

[pelajhia]

And if the report is accidentally saved still pointing to the 'wrong' db, then uploaded, does the admin attempt to repoint using the database screen 'custom' connection area?
If not, and the report fails, what error is received?
If so and the report fails, what error is received?

 

[pelajhia]

Also, what happens if one of these 'failing' published reports is opened in CR on the CE server?

 

[pelajhia]

please see if this applies:

http://support.businessobjects.com/library/kbase/articles/c2011875.asp

 

[pelajhia]

NattyCat,
I was curious if you ever got this figured out.
Partly because I am now having a problem which is almost the opposite:
I am running ce10 with cr10 reports using sql server stored procedures. When published and set to use original database connection info, the asp.net app accessing them has now problems. When set to custom data conn. info, the reports fail with this msg: 'sql server login failed'.
Sounds like you have been using ce + sql server based reports for a while and I wondered if you have ever seen anything like this.

 

[NattyCat]

Hi,

Whilst technically not solved, I have found a way around this problem.

In Control Panel>ODBC Settings I have several System DSN's, including Test1_database, UAT_database, Test2_database. the Login was always, for example, "username" and "password".

All I have done to fix this, is left the report looking at test1_database in the actual report (set datasource location) and when I want data from the UAT environment, or the Live environment, I go into the system dsn and change the database that the test1_database is looking at. So even though the database name is test1, it is actually looking at UAT, or Live for example.

Nat