Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Accessing a test database with Crystal Reports

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
I am working on a VB application that links to 20+ Crystal Reports depending on user choices. My problem is that the database is dynamic, and this makes it difficult to test when developing new reports or working on the application, since data isn't consistent.

Each users machine has an ODBC connection to the database which Crystal accesses. Each report points to this database in multiple locations, and with so many reports, it is impossible to change them all to point to a static test database when I'm developing. I've tried changing the database name I connect to in the ODBC settings on my test machine (while leaving the ODBC name the same), but my reports come up empty.

Is there a way to change the database the reports are pulled from without editting the reports themselves everytime? I would think this would be possible through my local ODBC settings, but can't get it to work.
 
Go to control Panel, 32 bit ODBC data sources and create a system DSN pointing to your test database. Then pull up a report you want to work with and click on Database, Convert Database Driver, and pick pdsodbc.dll. A dialog box will then come up and you can pick the System DSN that points to your test data, and save the report as some other name so the "live" report is still available. Software Support for Sage Mas90, Macola, Crystal Reports, Goldmine and MS Office
 
Jason,

We use crystal to develop, test and run on three different servers. (The test and development servers' database structure is exactly the same as the production server). We need to be able to switch back and forth quickly to test against fake and real data all the time.

We do this by stripping out the prefix on the table name in the Set Locations option under the Database menu item. So, if a table's name is "Party" when it is loaded it will have the prefix of development.dbo.Party. We delete the "development.dbo" and if the table's name is the same across the servers, there isn't a problem.

I don't know if this helps, but it works for us.

jonchaz
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top