Will V3 have better user filtering ?

Comments

• AlexTZ

  April 2004 edited 9:03AM

  No, all filtering should be done in a script or SQL query with parameters.
• Des

  April 2004 edited 9:03AM

  Thanks for the quick response Alex.
  
  Perhaps you could consider it for V4? It would be really useful for the user to be able to apply databand 'point and click' filtering/ordering to existing, stored reports.
  
  Thanks again
  
  Des
• AzzaAzza69

  April 2004 edited April 2004

  Des,
  Without wishing to upset you. ..but FastReport is a Report DESIGNER and not a Report GENERATOR!
  This request will more than likely be put to the very bottom of the wish list - along with other Report Generator options like the user being able to select actual fields, join tables/fields and sort order as it is outside the scope of a report designing tool.
• Des

  April 2004 edited 9:03AM

  AzzaAzza69 wrote:

  Des,
  Without wishing to upset you. ..but FastReport is a Report DESIGNER and not a Report GENERATOR!
  This request will more than likely be put to the very bottom of the wish list - along with other Report Generator options like the user being able to select actual fields, join tables/fields and sort order as it is outside the scope of a report designing tool.

  Thanks Azza, I can see your point.
  
  It's just a little bit frustrating as at the moment our app provides a lot of 'hand holding' (prior to letting the user create a report) that allows them to very easily set up the datasets that they need. Then the user is let loose on the designer (with everything already set up for them)
  
  It would be nice if once they have created and saved a report, the user could go back and 'tweak' its settings (ie basic filtering and ordering whilst still inside the designer) without having to go back and redo the whole dataset configuration.
  
  That way they could design themselves a report (eg 'employees'), save it, then when they load it back up they could then decide the criteria for which employees they wanted to print.
  
  I'm happy to work around it, I just thought it would be a natural progression for FR's development.
  
  Thanks again.
  
  Des
• Philnext

  April 2004 edited 9:03AM

  I think that the problem is not in FastReport (or in other report tool).
  
  If you wel know the customers' current needs (filters & orders) you may prepared it in a form with Delphi, when the customer have made his choices, he click on a button, it genere a Table and execute a report which use the Table.
  
  If the customers' need are not well known... he had to make some developpements with Delphi or in Fast Report.
• gordk St.Catherines On. Canada.

  April 2004 edited 9:03AM

  IMHO if you are afraid of the customer's abilities to design and write code for a report you should not supply a designer. and if you do supply a designer it is up to you(the app developer) to supply the extra help the end user will need, either in help files or code examples.
  regards
• Des

  April 2004 edited 9:03AM

  gordk wrote:

  IMHO if you are afraid of the customer's abilities to design and write code for a report you should not supply a designer. and if you do supply a designer it is up to you(the app developer) to supply the extra help the end user will need, either in help files or code examples.
  regards

  Hi Gord,
  
  I don't have a problem with the above, I will adapt FR to make it acceptable to our users. I only asked the original question as it would have been foolish to start making amendments if something better was to be introduced in FR3.
  
  On the subject of customer's abilities, we are switching from a much more expensive reporting package to FR, as after evaluating all the packages available, it was decided that only FR was easy enough for our customers to use without causing major headaches for our support team. Hopefully it's usability will not be lessened in V3.
  
  Thanks to everyone who responded.
  
  Des