Lazreport Designer expanded to include the ability to save reports in a database

[MaxLemberger]

I've expanded the Lazreport Designer to include the ability to save reports in a database (table). The designer has also been given a few more properties:

AskBeforeDBSave, DataField, DataSource, DBTemplateDir, SaveToDatabase.

The description is available as a PDF and is attached here. If you're interested in this option, please download and read the PDF file.

As usual, the database connection is via embedded Firebird – so it doesn't need to be installed – and ZEOS (must be installed via the Online Package Manager). I'm working with this combination and am very happy with it.  How to create a database in the program is also included as compact source code, but no further commented.

The new report component, along with a description and sample program, can be downloaded from this page:
https://lazarus.intern.ws/lazreport_designer_database.html

The English PDF file or description is attached to this topic and not included here to keep the post short.

Suggestions for the design and refinement of the designer are welcome.

The attached PDF file :

[JanRoza]

Very nice!
Would it be possible to use SQLite as database?
All my applications use SQLite and it would be nice if they could save reports in the same database.

[MaxLemberger]

I am very sure that you can take it with SQLite. You can check it first with ZEOS. You must change in ZConnection the Property LibraryLocation to your SQLite DLL and  Protocal from firebird to sqlite and maybe adjust the assignment of the database fields BLOB, String, etc. in the included SQL tables - this means adapting the creation of the database which is included to SQLite. Then creating the underlying database shouldn't be a problem. I'm busy with other things for about 14 days. If you can wait, I can take a look at it over the course of the next month. 

The database connection to the report Designer is independent of a database because only standard components are addressed. At least, that's how it's designed; I haven't tested it yet.

I take ZEOS for this:  to work with my programs also with other databases.

[JanRoza]

Thanks, I will experiment SQLite in the coming weeks.

[CharlyTango]

I am a fan of the idea of storing report definitions in databases, which would increase network capability. Quite an exciting and solid piece of work.

What I am not a fan of, however, is the way it is implemented.
The idea of having to manually copy the two files for the complete designer over the other files with every Lazarus installation is not sustainable in my opinion.
All other extensions for LazReport are offered in packages and that is also the concept of Lazarus.

If you look at the source, it took quite a bit of code to get LazReport to cooperate. My knowledge is not sufficient to be able to estimate whether this can be included in a package and if so, how.

But maybe the maintainer of LazReport is reading along and would like to integrate the function directly into the designer or at least prepare it so that a package is possible?

Does the maintainer of LazReport have an opinion on this?

[MaxLemberger]

  Yes. I know that overwriting a component isn't the best solution. However, since it was impossible for me to create a separate component for storing data in a database, and the effort would have been many times greater, I chose this approach. My idea was that Jesus, who has been working a lot on LazReport lately, might integrate this part. I sent him a message today about this.

If that doesn't happen, I'll continue the work and try to integrate the entire unit as a separate component. I haven't yet checked how far that's possible.

I also still need to adapt it for different languages. I've waited because I first need to know whether the change will be generally  adopted. 

[CharlyTango]

I also informed Jesus about your extension in a private message.
I also think that this would be a valuable contribution to LazReport.

If he does not adopt the idea, he may possibly be able to incorporate event procedures or hooks that would allow the extension to be integrated using a package.

[MaxLemberger]

"Outsourcing any properties or database functions to an external component (TReportStore) would keep the most important component, TfrReport, and the designer lean and clean." That's absolutely true, but then this component must also be structured accordingly and not be linked to other components.

Furthermore, no changes were made to TfrReport. I made sure that changes were only made to the designer component. This make the changes very compact.

Since I haven't received any feedback from Jesus, I've spent almost a day trying to figure out how to add the DBDesigner as a standalone component. In my opinion, it's almost impossible—especially with a reasonable amount of effort. You'd have to unravel so much and make changes to many components. See the uses alone:

Search "LR_Desgn" (12 hits in 12 files out of 67 searched)
R:\Lazarus\components\lazreport\source\lazreport.pas (1 hit)
Line 11: LR_About, LR_BarC, LR_BndEd, LR_Class, LR_Const, LR_DBSet, LR_Desgn,
R:\Lazarus\components\lazreport\source\lr_btyp.pas (1 hit)
Line 49: uses LR_Desgn, LR_DBDesgn;
R:\Lazarus\components\lazreport\source\lr_desgn.pas (1 hit)
Line 10: unit LR_Desgn, LR_DBDesgn;
R:\Lazarus\components\lazreport\source\lr_desgn_Error.pas (1 hit)
Line 11: unit LR_Desgn, LR_DBDesgn;
R:\Lazarus\components\lazreport\source\lr_design_ins_filed.pas (1 hit)
Line 60: uses LR_Utils, LR_Class, LR_DBRel, LR_Desgn, LR_DBDesgn, LR_Const;
R:\Lazarus\components\lazreport\source\lr_edit.pas (1 hit)
Line 78: uses LR_Desgn, LR_DBDesgn, LR_Fmted, LR_Var, LR_Flds, LR_Const, lr_expres, strutils;
R:\Lazarus\components\lazreport\source\lr_gedit.pas (1 hit)
Line 56: uses LR_Class, LR_Desgn, LR_DBDesgn;
R:\Lazarus\components\lazreport\source\lr_hilit.pas (1 hit)
Line 60: uses LR_Desgn, LR_DBDesgn, LR_Class;
R:\Lazarus\components\lazreport\source\lr_newrp.pas (1 hit)
Line 48: uses LR_Class, LR_Desgn, LR_DBDesgn;
R:\Lazarus\components\lazreport\source\lr_register.pas (1 hit)
Line 11: LR_Desgn,
R:\Lazarus\components\lazreport\source\lr_view.pas (1 hit)
Line 746: // see lr_desgn.pas:TfrDesignerForm.SaveState;
R:\Lazarus\components\lazreport\source\_lr_desgn.pas (1 hit)
Line 11: unit LR_Desgn;

These dependencies alone make a separate component pretty obsolete. I've tidied up the Designer component a bit and defined the text used there as a
. resourcestring
so that different languages can be used. I will make the reworked component available on the page
.
https://lazarus.intern.ws/lazreport_designer_database.html
in the next few days. For me, the topic of custom components is closed.

It's not that much work to add the two files to the source folder. I have four changes that I make to the components with every version change. I've documented this for myself, and it takes a maximum of six to seven minutes to accomplish. Now it's just two minutes longer.

And maybe someone will come up with the idea of including the component in this form as a standard component. Everything speaks for it. The component doesn't have that much more code.
lr_desgn.lfm: about 0 bytes
lr_desgn.pas: about 12 KB

If anyone has more experience with components and finds a way to create their own component, that would be great.

If anyone knows how to submit it, they're welcome to do so. I haven't done anything like this before and don't have any more time.

Note: I haven't covered subreports (yet).

[jesusr]

In fact, the support for save/load reports from datasets has been implemented in 2013, check this log https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/606d865ad316534dedb56c77a0783d6f87ee7bca, the provided code is a step forward, the comments in the test program are appreciated and the comment delimiters in the changed sources helped a little, but are not desirable in the final code. If I read it right, there are really few changes required in TfrDesigner/form designer in order to move everything to an independent component, which is the preferred solution. Such component could use OnLoadReport and OnSaveReport and if those events have to be modified (preserving compatibility) please let me know and I will help you.

[Soner]

In fact, the support for save/load reports from datasets has been implemented in 2013, check this log https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/606d865ad316534dedb56c77a0783d6f87ee7bca, the provided code is a step forward, the comments in the test program are appreciated and the comment delimiters in the changed sources helped a little, but are not desirable in the final code. If I read it right, there are really few changes required in TfrDesigner/form designer in order to move everything to an independent component, which is the preferred solution. Such component could use OnLoadReport and OnSaveReport and if those events have to be modified (preserving compatibility) please let me know and I will help you.

I think the 2013 solution is good enough, it just needs to be improved because loading doesn't work properly; it is only saved in the old format (binary). I have posted examples in the German forum.

[jesusr]

I added a sample using pieces from here and there, it is in lazreport/samples/reportfromdb, it can be used as basis for future improvements.

[CharlyTango]

Thank you for your dedication.