Switching database once Report is developed 3

[pelajhia]

Two part question:

I am wondering if it is generally good practice to develop one's reports against a 'test' database and then once they are how you want them, point them to a production database.
Is it even possible to move a report to another database without loosing all the fields?

It seems like it ought to be, (I mean people convert reports all the time, right?) so I'm probably missing something very obvious. I'm unable to test this question right now, but will be able to hopefully in a few weeks. In the meantime, if anybody just knows the answer/procedure or any pitfalls to beware of, that'd be great.
Thanks!

 

[lyanch]

Go to Database->set location and point to the new database and letting it propogate location across all tables/subreports. This function is considerably more stable than it was a few years ago. There are a few glitches, sometimes different names will not propogate correctly and sometimes it just doesn't seem to correctly change..

If the databases are on separate servers, it is easy to check. Close Crystal reports, reopen and run the switched report.. it should only ask you to log on to the new server..

Lisa

 

[scottcable]

Similar problem in that we have 3 envronments
Development, Test and Production.

I should be able to edit a report once and not have to touch it when it is copied to the various evironments (we use the same DSNs for each area).

However Crystal now seems to reference the physical database name in addition to the ODBC System DSN.

Does this mean that when I distribute a report from Development to Test I have to open the report and perform a Database->Set Location for every report that has been modified/created for the current release of code ? And then do this all over again when we move them to Poduction ????

Or am I missing something ?

Thanks in advance for any help.

Scott

 

[morriskc]

I always create an alias for my database connection & use that alias for connecting my report to the database. This way, when I switch from dev to test to production, I am switching the sql.ini file on my machine & not touching the report.

 

[lyanch]

You can remove the database reference from withing database -> set location. You will need to do it for each individual table/sp. It is a blessing and a curse that Crystal remembers the database name. I have one test/dev server that contains several versions of the same DB.. if I didn't have the DB then I would never know which DB I was pointing to. On the other hand, once anything is past this server ie final test and production, there is only one db..

such goes life...

Lisa

 

[scottcable]

Thanks for your input guys. I've just picked up this Crystal stuff from someone who has just left and so I'm new to the Crystal "buggy" culture. It turns out that this is a problem that Crystal have been informed of - although no news of a fix as yet.

As stated by Lisa removing the database reference via the Database->Set Location menu is a workaround. It seems that you do have to leave a reference to the stored procedure name though eg) DBName_Proc(sp_name;1) becomes Proc(sp_name;1)

Thanks again

Scott

 

[CrystalReports9]

I have crystal report9 that to be run on 9 different databases, with the user selecting which database supplies the data for the report (the tables are the same in each database).

I have successfully done this with a single database using the RDC combined with the LogOnServer method. But it fails for calling another database. I got the error message "Logon Failed"

Pls give me the solution for multiple database using native oracle database driver dll crdb_oracle.dll

Environment
-----------
Crystal Report 9
ORACLE 8i
Power Builder8.0
Windows NT