D
Danny J. Lesandrini
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 project?
2) Rolling out new .rpt files to clients where the report tool is already installed.
So, once my user installs the report tool with its initial load of stock reports,
how do I roll out new .rpt files? Any suggestions?
FWIW, I architected the app to look for and load individual Crystal Report .rpt
files so that users could, if they wanted, tweak the report formatting. They
are not embedded and/or compiled into the app, which means that to roll out a
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 application,
on startup, looks for any .sql files and executes them. They might include new
views, procs, and/or a script that loads the names and attributes of the new report
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 and
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 hundreds
of clients distributed across the country is going to be a bear. Any Suggestions?
I attended Dev Days where we saw the implementation of the Application Updater
block. It works slick, but each time it updates the application, it creates a new
application folder, like this ...
Program Files\
MyApp\
v1.0
v1.1
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. Clients
would hit my web service each time the app starts up to see if there are any new
reports to download. What if they aren't online? What if I want to deploy one
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.
Thanks
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 project?
2) Rolling out new .rpt files to clients where the report tool is already installed.
So, once my user installs the report tool with its initial load of stock reports,
how do I roll out new .rpt files? Any suggestions?
FWIW, I architected the app to look for and load individual Crystal Report .rpt
files so that users could, if they wanted, tweak the report formatting. They
are not embedded and/or compiled into the app, which means that to roll out a
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 application,
on startup, looks for any .sql files and executes them. They might include new
views, procs, and/or a script that loads the names and attributes of the new report
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 and
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 hundreds
of clients distributed across the country is going to be a bear. Any Suggestions?
I attended Dev Days where we saw the implementation of the Application Updater
block. It works slick, but each time it updates the application, it creates a new
application folder, like this ...
Program Files\
MyApp\
v1.0
v1.1
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. Clients
would hit my web service each time the app starts up to see if there are any new
reports to download. What if they aren't online? What if I want to deploy one
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.
Thanks