Hi folks,

in the last days I have been testing the use of MemoExecDQL / ExecDQL functions. It seems very powerful and I would like to use it instead the "null printer hack" to speed up and streamline my application. But during my tests I noticed that every time the keyword "in groups" is in the DQL script, the ExecDQL function does not work. The DQL is simply not executed. So please clarify this issue. Furthermore, it will be very useful if you could provide further examples of this powerful function.

Thanks.

Is anybody in there?

Sorry for the late reply. We are currently working full out on 8.2 where DQL will be further enhanced.

ExecDQL is DQL from "future" DataEase and is not derived from the existing DQL in DFW. Somewhere along the line someone "misunderstood" DQL and renamed it from Advanced Procedure (DFD) to Advanced Report (DFW). This was possibly done because most reports would end up being converted to DQLs in DFD due to the lack of Data-Entry forms and the "wish" to do some kind of status update after a report was printed etc.

In DFW and especially in DE8.x this is no longer needed. There is million ways of executing a Report by using GetVar()/SetVar()  Open related etc, to execute a report without the need for the traditional Data-Entry form etc.

It is no secret that the DQL in DFW has been fraught with problems and challenges. It was/is a bad "reporting" tool, and it is an even worse Trigger/Procedure.

ExecDQL was implemented so the power of DQL as a procedural language should be properly released in DE8. ExecDQL was primarily made to do transactions, either in the function of a stored procedure or in emulating trigger functionality.

As it turned out, it could do much more than that. Combined with the SetClass you can use it to manipulate the form directly etc.

But back to the "original" intention. We wanted a tool that could fill in two gaps:

1. Silent/Invisible transactions/triggers. - Using a traditional DQL to do these things would either cause the problem with output (and employing the different hacks to avoid it as null printer, export to etc..) but at least you would have some blinking and opening of separate documents with the DQL which would both be "slow" and cause all kinds of procedural problems/resizing of windows etc.

2. Export - Something that was so simple in DFD because so difficult in DFW... This is why ExecDQL will generate a Export file if you add a file name as the last parameter.

We have to admit that this was the "limited" scope of ExecDQL, but by creating it we let the genie out of the bottle. It turned out that by calling a ExecDQL you could suddenly get "finger tip" control of you programming.

But back to your question about Groups etc.

ExecDQL is using the same parser logic as normal DQL for compatibility reasons, but it is built from scratch so functionality is included rather than being there by default. ExecDQl is not a reporting tool and Groups etc, is aggregation functions which doesn't correspond with the logic of transactions etc.

Logically you can't use the Group functionality in the DQL i.e. in the transaction itself so it serves no purpose other than confusing the "subject" here.

DQL is big and complex so at the moment some of these functions are simply "blinded" out and they shouldn't stop the entire DQL from working when included which is unfortunate, and it will be rectified as things progress.

Another thing that will cause the same thing at the moment is multiple For loops and Multiple List records.

ExecDQL still have a lot of weaknesses but the strengths outweigh them by many miles, and all of the weaknesses can be circumvented easily:

If you want to group simply use multiple in Order on the columns in questions and use variables to check when they change value and variables to keep the sums/counts etc. You will have to do this anyway even with Groups so groups in this context would simply be the same as order.

If you want to run multiple for's etc, simply split them up in separate ExecDQLs. You can call one ExecDQL from another easily by using the function in the DQL.

retval := MemoExecDQL(any ExecDQLStore with DQLNr=temp DQL,DataEntryVar1,......

We now also have a LabelExecDQL() which allow you to write the DQL directly into your form as a label and execute it with this function.
You obviously hide the DQL with SetState().

Examples!

We are currently working with finalising DE8.x. We are currently updating QBM and DQL (Documents) so they will actually work "as intended".

The approach is that the Developer should be able to effectively build a layout and keep it without interference from DataEase i.e. auto regen layout...

This is something that has annoyed DE users for 20 years, and will be the final fix in DE8 before we fully release it and concentrate on documentation/sales and use.