I know you would suggest that we use ExecDQL in DE8.

But, I had a question to why we should use it. As it does not have any formula or validation check build-in.

If I want to use ExecDQL, I have to always check the DQL in our old DQL editor to make sure it works, then use ExecDQL.

Could you please tell me some benefits of using ExecDQL ?

You need to change your understanding of DQL to have any use of ExecDQL.

I think we need to start breaking down some walls/misconceptions here.

1. DQL is the query/transaction language of DataEase and not a reporting language. In DFW DQL has been “interpreted” as “Advanced Reports” when it is DFD always was called “Advanced Procedures”.

In DFW DQL has been very limited by the confined space it was implemented in. in DFD it was easy to run a DQL without a Data-entry or a Body or just one of them, but in DFW the entire heavy and cumbersome GUI part is always present.

In DFW DQL was implemented as a “Document” on par with Report and Form, but in reality it is a script that should in most cases just be executed within a form.

ExecDQL is a different way of using DQL where you can call it from anywhere without any “luggage” and it is called as an integral part of the document from which it is executed.

If you on a button or in a derivation in a form use “OpenProcedure()” it will load the DQL as a document like “DcoumentOpen()”, switch to that document, do its business and finally return to the Form from where it was executed.

With ExecDQL you simply execute the script.

DQL has been perceived as heavy, because the “heavy” implementation of DQL in DFW, but DQL is everything but heavy!

Just think. When you execute a traditional DQL (even one that just update something without data-entry or body) you have more than enough time to get annoyed with the flickering, opening, refreshing etc. before it finally finishes. That is because it works in “human” time. If all of that happened so fast that you couldn’t see it, it wouldn’t be annoying…

Imagine that you remove all of that loading, opening, flickering, switching, refreshing and simply do the job…then we are talking nanoseconds for executing the same DQL.

So when we realise that the execution of the DQL script itself is less than 1/1000 of a percent of a percent of the actual processing that happens when executing a DFW DQL, what then if we just execute the DQL Script and drop the rest?

Magic.

DQL is extremely underused in traditional DataEase because of its cumbersome implementations, so with the implementation of ExecDQL you can suddenly start using it for everything. You can use it for Validation Check, manipulating data in the form directly, updating data in tables on the fly … only the imagination is the limit.

2. "As it does not have any formula or validation check build-in.

If I want to use ExecDQL, I have to always check the DQL in our old DQL editor to make sure it works, then use ExecDQL."

There is the same formula/validation checking in ExecDQL as in the old DQL editor. Running and Checking a DQL is done by the same parser, so when you try to execute a ExecDQL script you will get the same error messages as you do when you parse in the traditional DQL editor.

As we are all very aware of, the interactive help that DFD was so famous for is missing in trad DFW DQl and also in ExecDQL. This will be remedied with DE8 Reporter, but as execDQL is something that can be invoked from anywhere, you will have to test the script before you execute it.

We simply use a form we normally call ExecDQLStore where we write and save all the MemoExecDQL() scripts we use in an app, the we simply lookup the scripts from this table and execute them anywhere.

ExecDQL is a handful and as it is now, it is definitely a programmers tool, but when one gets the hang of it you start wondering how you could develop applications in DataEase for Windows before it.