By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,080 Members | 1,817 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,080 IT Pros & Developers. It's quick & easy.

How to distribute new Crystal Report .rpt files?

P: n/a
Didn't get any takers on this post this morning at dotnet.General, so I'm
reposting here.
First, this is _not_ a question about how to get Crystal Reports to run
on a client machine. I've got all the merge modules added to the project
and it's working fine. The question is about distributing my .RPT files.

1) Initial Setup Project inclusion of .rpt files:
My folder of new .RPT files keeps growing. Is there a way to point
my deployment/setup project to the folder containing these .RPT files
so they are added automatically, or must I add each newly created
report to the deployment project manually?

a) Would I create my own Merge Project with these report files?
b) Do I use the mysterious Project Output | Content Files?
c) Can I simply point to my Primary Project folder from the Setup

2) Rolling out new .rpt files to clients where the report tool is already
So, once my user installs the report tool with its initial load of stock
how do I roll out new .rpt files? Any suggestions?

FWIW, I architected the app to look for and load individual Crystal Report
files so that users could, if they wanted, tweak the report formatting.
are not embedded and/or compiled into the app, which means that to roll out
new report, all I have to do is xcopy it to the Reports folder.

Each of my reports is based on a unique SQL Server stored proc. The
on startup, looks for any .sql files and executes them. They might include
views, procs, and/or a script that loads the names and attributes of the new
into my Reports table, thus informing the front end app that the report
exists. When
the user requests the report, the app looks up the name of the proc and
checks to
see what filter parameters must be supplied, loads the data into a dataset
crams it into the report object, which points to the new .rpt file.

This paradigm works great, but deploying new reports, one at a time, to
of clients distributed across the country is going to be a bear. Any
I attended Dev Days where we saw the implementation of the Application
block. It works slick, but each time it updates the application, it creates
a new
application folder, like this ...

Program Files\

With this paradigm, the users will have an entirely new application version
with the
rollout of each new report. That doesn't really fit my needs. I may need
to do
that in addition to rolling out single reports, but there must be a
light-weight way
to distribute individual files to distributed users.

WEB SERVICES? That's my next path, but I'm not sure where to start.
would hit my web service each time the app starts up to see if there are any
reports to download. What if they aren't online? What if I want to deploy
report to one client only and another to all clients. Maybe the list of
reports will
be table driven by client ID. I don't know. I'm open to ideas.

Danny J. Lesandrini

Nov 20 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.