In the DQL menu you have the "Document Print Options". There is an new Option " No Output". What is it for / what is the function?

No Output was implemented in DE 7.2 for many of the same initial reasons for doing ExecDQL().

The exact problem you were having with the body after using List Records is why this was implemented.

However...

The problem is the original implementation of DQL back in 1994!

It was a "botched" job that has created headaches for developers and users ever since. DQL from DFD was merged with QBM from DFW and the result is the DQL "Document" that we have struggled with ever since.

To make this unhappy marriage works some core functions some core functions like sorting/grouping/listing had to be replicated in the GUI (QBM) so a DQL Document in DFW actually run through twice.

A Prism DQL is finsihed long before you see any output on any screen, the output is generated on the second run through of the DQL where the result is grouped etc.

So far everything is straightforward, especially if the job had been done properly and this is where the "botched" job comes in.

Even though the implementation was never ideal it would have been much better if it had been done like a proper job, but it was a rushed "hack" so it never was.

The functionality that generate the output is too linked with the functionality that do the sorting/output in GUI and to make matters worse, this functionality is (due to the crazy Document model in DFW) shared with Forms and Reports.

The No Output option is "partly" implemented in 7.2/8.0 which means that it works in some use cases, but to make it work like it should it means re-writing Forms/Reporting/DQL and that is what we are doing in 8.

So the short story is that it doesn't work ;-)

It is no point fixing a DQL approach that is idologically flawed from the start, so we are finally splitting up forms and reports/prints and are making procedures independent of output.

DQL has nothing to do with printing or reporting, it is query/transaction language for manipulation.

ExecDQL is one implmentation of DQL where you use DQL as a function.
DE8 Reporter is the next step.

When you use "list records" in a DQL you automatically create a view (in DE terms a Multi-View). This is the same view you get when you query a Form or Run a Report.

It is basically a flat view that contains all the columns in the query. So if you have a from with several subforms, the multiview will return with one column for each field in all of them where the data in the main record is repeated in each row for the data in the sub form.

This multi-view is then used in the GUI to present the data to the user. There is no difference between a multi-view when you query a form, report or a DQL.

So in DE8 Reporter you will be able to simply build a report on top of the multi-view generated by the DQL the same way you can build a report on top of a table.

Both ExecDQL() and DE8 Reporter use PRISM and DQL from DG3 where all the functions moved into the GUI in DFW has been reverted to their rightful place in PRISM. This means vastly improved performance and complete lack of GUI flickering and problems.

We know at this stage that ExecDQL can be a little "inaccessible" due to the fact of a lack of editor for it. This will be amended when we release DE8 Reporter and DE8 (Native). You will then be able to edit an ExecDQL directly in DE8 Reporter and save it back into the database.

For now, you can use the DQL Gui in DFW to generate and test your DQL and then simply copy it into your ExecDQL Store for use in the App.

Just remember that data-entry values in ExecDQL is always called data-entry field1 through field4 due to the parameter input of the function.

Good luck!

I think I understand that all now. But I found a very easy way for solving the problem in DFW 6.53:

in the procedur you go in "Document Print Options" "Print to :File" and "print without displaying" and a filename "c:\xxx.txt".

So the problem is solved. In DE8 you do not have this joice and the "no output" does not work, as you mentioned.

Download Sample

If you are just looking for a way to "fool" DataEase into not generating any visual output there is several ways, just remember that all the work-around's actually generate all the output and use all the "slow" features. If you use ExecDQL, it simply isn't just no output, it is also 100-1000s of times faster than the "normal" DQL and you can use it everywhere as an integral part of your programming.

But first the resulting times when updating 18.000 records in our test app:

Not a hack! ExecDQL: 0 seconds (not measurable in seconds...)
Hack #1: Export Hack. 37 seconds.

Hack #2: Printing to Null device: 1:14 seconds.

Hack #1:

Simply add export to the DQL.

This export hack was made to allow for exporting text to files i.e. DFD DQL's in DFW.. It was never very good and it is slow, but to achieve no output DQL's with List Records (Sorting) it is the best.

for Customers ;
list records
CustomerName in order .
modify records
Contact := Concat("ExportMethod: ",current time, " ", current date ).
end
export to "nul" .
.form header
.items
@f[1,1]
.end

Hack #2

Hack number two is like the printing to file hack in 6.53 but with the improvement of not having to save it to file at all. Nul device exist in all windows version and is like a black hole. You can use it as a terminator of a stream as no output is generated/saved or displayed. It is simply truncated.

To get this too work you need to also set up the printer in your printers.

But in all honesty, stop using these hacks and get on-top of ExecDQL, as you can tell from the results above, the difference is staggering.

With ExecDQL you can use DQL to do anything for you, with these hacks you quickly see that you spend a lot of time/energy to do very little.

Add to that that ExecDQL can manipulate directly into your form too and it's not a contest. It never was....;-)

If you wan to make a report, simply enter the date in a table with ExecDQL or append it to a Memo or a text file and then simply open the report, the form or print it directly with PrintMemo() or PrintHTML(). The result is better, the speed is better, and the context is better.