Link to home
Start Free TrialLog in
Avatar of Dee
DeeFlag for United States of America

asked on

Do I really need 130 executables? How to manage?

Assignment:  Create new report system consisting of 130+ reports using Delphi and FastReports.

At this point I have created about 12 test reports.  The app(s) load them into a report viewer component dropped on the main form that contains  a custom tool bar -  all the controls on the toolbar are exact from report to report (print, zoom, goto, etc.) except for tool for exporting the report in various formats.  The report name will vary of course.

The pre-processing prior to generating each report is

1.  Get Input parameters (command line).  1 parameter will be a code that identifies the report.  The remaining are SP parameters.
2.  Execute stored procedure using input parameters
3.  Run several functions that returns report vars (ie logo file path)
4.  Load the fr3 report from file based on step 1 parm
5.  Set report vars (logo path, report header, etc)
6.  Display report in report viewer on main form which contains the custom toolbar.

I have been steered toward creating a separate exe for each report.  Several weeks and several makeovers of the test reports, I am hit with the reality of possibly having to recompile 130 executables at some point.

What is the best way to handle this?

Any response that has to do with OOP, please be very specific.  I have studied it fiercely and think I have a good handle on the concepts, but have not coded any application that I would consider fully OOPed.  I am endeavoring to make this the first.
Avatar of Sinisa Vuk
Sinisa Vuk
Flag of Croatia image

This make no sense what you doing. Create just one exe/previewer and pass report  filename (fp3,fp4) , designed and saved before in one folder. Your previewer can be part of your application too.
I had a similar problem for a rental software I wrote a couple years ago.
One of the requirements was the ability to create / run custom reports on the client side.
I just throw at you a few ideas collected during my experience:
- if you don't know the datasources at compile time, then you have to create them into the report, in the data page. In this case, you may want to share a single connection across the reports. To do so, drop a connection on your form (e.g. an ADO connection), then point the frxADOComponents DefaultDatabase property at it;
- drop any frx runtime component you may need on your form (database components, barcodes, ole, gradients, blah blah blah);
- do NOT use FastReport variables to pass data to the report. They're a complete mess. If you need to pass arbitrary (named) parameters to the report, you may follow this approach:
1) parse the command line looking for parameters in the form name=value, and collect these pairs in a TStringList;
2) upon start, add a custom function to your report engine, that returns param value;
3) inside the report, you can use the custom function whenever you need it.
sample code:
procedure TForm1.FormCreate(Sender: TObject);
  i: Integer;
  frxReport1.AddFunction('function GetCustomParameter(const Name: string): variant', 'custom functions');
  FCustomParams := TStringList.Create;
  FCustomParams.NameValueSeparator := '=';
  for i := 1 to ParamCount do
    if Pos('=', ParamStr(i)) > 0 then

function TForm1.frxReport1UserFunction(const MethodName: string;
  var Params: Variant): Variant;
  if SameText(MethodName, 'GetCustomParameter') then
    Result := FCustomParams.Values[Params[0]]
    Result := Unassigned;

Open in new window

now imagine to invoke your exe with this command line:
yourexe.exe reportname.fr3 SP_storedproc1 SP_storedproc2 ... param1=value1 param2=value2
into the report you can do:
procedure Page1OnBeforePrint(Sender: TfrxComponent);
  v: variant;                                           
  v := GetCustomParameter('param1');

Open in new window

the overall design of using a single exe / report object to load multiple fr3 files looks good to me, as long as you carefully evaluate your reports' requirements and design an execution environment that fit to all of them.
the one report = one exe paradigm is horrible :)
Avatar of Dee


Thanks Lomo.  I have coded and implemented all the logic outlined in my steps on the test reports that I have working now, and have the appropriate FR components on my form for db connection, stored procedure, exports for PDF, csv, etc, as well as parsing the command line parms on form create.  I will probably plug in your functions as they are cleaner and more concise than what I coded.  Thanks.

As well, I am using “frx.LoadFromFile” to load the fr3’s that I have designed at run time according to the report code in the parm list, no problem on any of the above

Ok, so … assuming I have now, or at some point in time :) , thoroughly evaluated the report requirements.  Here’s my dilemma – 1 SP for 1 report equals 130+ stored procedures.  

How do I structure my code, aside from maintaining 130+ executables? (nightmares already invoked on that thought..)     Code 130+ procs in my executable – 1 for each report/SP?  That would be a big mess too, right?  Yep

+++  Any ideas here as far as my code structure? +++
Please, be more specific on what your requirements are (or might be).
What are those 130+ stored procedures supposed to do?
Avatar of Dee


The store procedure(s) pull the data for the report into a table.  The report uses an adoquery to populate the report from the data table generated by the SP.
Avatar of lomo74
Flag of Italy image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial