Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / May 2004

Tip: Looking for answers? Try searching our database.

How to deploy new report files to distributed clients?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Danny J. Lesandrini - 07 May 2004 18:33 GMT
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 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
Signature

Danny J. Lesandrini
dlesandrini@hotmail.com
http://amazecreations.com/datafast/

Greg Shaw - 08 May 2004 08:48 GMT
Danny,
On the Deployment project question what I did was to include the
Source files of my Reports project and then apply an exclude filter
removing the *.csproj, *.cs and *.resx files. Now I know whenever I build
the Setup project all .rpt files will automatically be included.

I don't have any easy ideas for the incremental rollout unfortunately.
I will need to face this one myself in the near future.

Cheers, Greg.

> Didn't get any takers on this post this morning at dotnet.General, so
> I'm reposting here.
[quoted text clipped - 20 lines]
>
> Thanks
Danny J. Lesandrini - 10 May 2004 14:52 GMT
Greg:

Great idea!  That is exactly what I was looking for.  I realized I could include
source files, but didn't realize I could filter out my code files.

Thanks much!
Signature


Danny J. Lesandrini
dlesandrini@hotmail.com
http://amazecreations.com/datafast/

"Greg Shaw" <greg@nospam.com.au> wrote> Danny,

> On the Deployment project question what I did was to include the
> Source files of my Reports project and then apply an exclude filter
[quoted text clipped - 5 lines]
>
> Cheers, Greg.
Danny J. Lesandrini - 10 May 2004 15:13 GMT
Greg:

I need to do research on this, but I hit a glitch.  I excluded
everything except  .rpt and  .sql   but only my .rpt files are
being included as "source" files.   The .sql files are sql scripts
that I want to deploy.  These scripts are processed automatically
when the app starts up, loading required procs and views.

Apparently, sql files are not considered "source" files.  Grrrr!

I'll test it further and check google for previous posts on this
issue, but it's frustrating.  I'm half way there.  Thanks again
for your suggestion.
Signature


Danny J. Lesandrini
dlesandrini@hotmail.com
http://amazecreations.com/datafast/

> Danny,
> On the Deployment project question what I did was to include the
[quoted text clipped - 6 lines]
>
> Cheers, Greg.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.