Re: [gnome-db] Re: Multiple queries in report stuff

[Santi Camps <santi gnome-db org>]

El mar, 21-01-2003 a las 14:12, Vivien Malerba STNA 7FD M204 escribió:
> Le mar 21/01/2003 à 14:02, Rodrigo Moya a écrit :
> > On Tue, 2003-01-21 at 11:22, Vivien Malerba STNA 7FD M204 wrote:
> > > > Do you think that this could be interesting, or it's better not to
> > > > reinvent the wheel and do the same that other engines ?
> > > > 
> > > 
> > > I really like what you propose, it is much more powerfull and easy to
> > > understand. It is also very easy to generate from mergeant (and making a
> > > graphical tool to create reports would be easy).
> > > 

I'm really enjoy that this could help to do the GUI easier.


> > oh, cool to hear, but could you ellaborate a bit more on why it would be
> > easy to do? I think we really need a graphic reporting tool before 1.0,
> > and given the work Santi is putting on the GDA part, it would be really
> > cool if adding a GUI for that is easy.
> > 
> > So, please, tell us why is it so easy so that we can start implementing
> > it. :-)
> 
> I did not mean very easy, but not very difficult. Basically I had two
> ideas in mind.
> 1st idea:
> ---------
> Queries defined in mergeant can contain related sub queries (well, the
> editor does not really allow it for now but it's the idea), and so, to
> take the example of Santi, we can define a query named "query_bank",
> then a sub query named "query_office" which is related to the previous
> query by "bank_id=query_bank.id_bank", then a sub-sub query named
> "query_customer" related to the previous one by "office_id =
> query_office.office_id" etc...
> 
> Then creating a report is just a matter of inserting some text before
> each query, and we can generate the <detail></detail> part; the
> different <sql_query></sql_query> parts are also easy to generate from
> the queries organisation mentionned in the 1st paragraph.
> 
> 2nd idea:
> ---------
> To take Santi's example, all the queries are defined independantly of
> each other, some of the queries are defined with parameters (as it is
> possible to do now).
> - "query_bank": no parameter
> - "query_office": 1 parameter which is bank_id
> - "query_customer": 1 parameter which is office_id
> - "query_accounts": 2 parameters which are customer_id and office_id.
> 
> Rem: each query can be executed independantly of the other ones; the
> missing parameters will the be asked in the same way you did for the
> 'SQL console' queries.
> 
> Then I don't think is it too difficult to create some new kind of canvas
> items to allow the user to organize queries and connexions between
> queries for a report, on a canvas. For a small and dirty illustration of
> what it could look like, see the joined picture (and the associated DIA
> file): the appendices on the right of each query are the possible
> parameters which we can connect to 'fields' (columns) of other queries.
> 
> Also, for example, if we defined a "bank_name" parameter for the
> "query_bank", then we could make the whole report depend on that
> parameter (which would be asked before the report's generation).
> 
> I think the 2nd idea is really better.
> 
> Rem: both ideas are really only easy to implement in mergeant and not in
> libgnomedb because it requires the notion of (structured) queries which
> are not defined in libgnomedb.
> 
> What do you think?
> 
> Vivien

It sounds very well, specially the second idea.  

To have a canvas where queries are defined and relationed.  Then, each
<detail> in the report should also be relationed with a query, shouldn't
it ?

We should also oversee that there isn't cycle dependencies, but it can
be done.  

I like it.  Perhaps it could be usefull for a lot of users some way to
generate this query-map from the tables and relations structure, or
something like this.  

I sounds hard, but a lot of reports designers doesn't know nothing about
SQL.  That is one of the best goals of Crystal Reports, everybody can
use it.  I think we should keep this in mind, shouldn't we ?

Cheers

Santi