The DQL body Layout of Despair

Do you recognise this? If you do, you are not the only one. In 7.5 our focus is on moving DataEase for Windows into the 21st Century, but instead of attacking the core product - that is called DataEase Generation 3 - we try to include new functionality that can help the users that has invested in DataEase for Windows, to move their application forward and take advantage of new functionality.

The basis of the improvements in 7.5 is very much a result of the DataEase Generation 3 project, so it is only natural that HTML is a big part of "how" we improve DFW.

In this article we will try to explain why DQL body is the way it is, and how we are developing a workaround in 7.5

As you know the "layout" on DQL's is a constant nightmare. I am afraid the way it was implemented was a "rush" job back in 1994, and we have suffered ever since. To use an absolute graphical format for a Report is not very good on its own, but the main problem is that there is no "boss" in DQL's. The DFW DQL is a hybrid between DFD DQL, and DFW Reports and they could never make up their mind to whom is the boss. The DFW report was developed to be built on top of a table (with subform) and then it could be "extended" with form virtual fields own by the Report itself and stored in the FRM file rather than the .TDF file. All of the above create a PRISM MultiView. There is no "stored" views in DataEase, everything is ad-hoc. The only "fixed" item is the .TDF/DBM structure. The only time the MultiView and TDF corresponds 100 % is when you create a form on a table with no Subform and without any sorting or filtering, but even than it is "imaginary", just waiting to create a "morphed" MultiView. The moment you search for something, you get a completely new Multiview, and every time you "play" with the form again a new one. There is no link in TDF between forms and subform, that is a logical link stored in the FRM. There is no link between a .TDF and a "Form Virtual" field either, that too is stored only in the .FRM and added onto the ad-hoc query that builds the MultiView. The MultiView simply looks like a CSV export where all the columns of the main table is repeated for each record in the sub table etc. Sorry, for the long introduction, but it is essential for understanding why DQL Layout is so "unfortunate". When the created DQL they followed the "idea" from Express and "overhyped" Object oriented WIndows programming of the early 90ies, and deducted that a Print/Report/Form is all the same, just used differently, so they decided to use the same approach to both and in the extension also for DQL. This "Might" be true for QBM reports, because you can dynamically add and remove fields etc from the layout, but to combine the sequential thinking of DQL with the object thinking for QBM is madness, and time has proved us right. This could only ever work "idealistically", since in DQL it is the List Records that decide which columns to be "listed", sorted, summed, derived in the Body, when in QBM it is stored in the FRM based on the selections one make in the QBM. So far it sounds like they can be matched up, and they where, but then the problems enter. QBM can only pick and derive based on the tables that build the Multiview. All the "virtual" columns derived in the List Records cannot be selected because the MultiView is already created by the DQL and is one step removed from how the QBM is designed. So to "alleviate" this problem the DQL push the Virtual fields (ex. My Price*My Discount*VAT or temp AllOverCount) into the body so they now also is part of the QBM body. So far all is good, you can move them around and make it look "Nice". You can also insert columns and make form virtual fields in the Body as much as you like. But then you need to adjust something in the DQL. You want to add a column, or change the sort order.... What happens? There is no link between the body and the DQL, so the only way the DQL can insure that the changes is transported into the Body is again by "Pushing" them in. It tries to re-create it, but since it know nothing of the changes it didn't do itself it removes all the changes you did directly in the Layout, and pushes back all the columns in the List Records. As if this wasn't bad enough. The way this is done in 7.x is "vastly" improved over how this was done in DFW 5.x. In 5.x there was no consideration at all, when the DQL decided that the layout needed to be rebuild, it simply quashed it. The reason you get problems with the Layouts in DQLs when you migrate from 5.x to 7.x is that due to changes in character sets, the code is parsed and changed. If it is English, it will cause no problems....but since it is German(or Norwegian in my case) national letters is exchanged for the correct ones in our language, and voila....a rebuild is necessary. In DG3 we have of course "learnt our lesson" and there is no links like this anywhere. We make it completely opportunistic i.e. we assume that the columns you insert in your Layout exist in the Multiview, and if it doesn't nothing happens, it is just left blank. Since 7.5 is a version to try to take DFW applications a little longer, we will take advantage of the Export exception to allow you to build a DFD type body on a DQL to print or view but we top it with making it HTML, so you can also format it using HTML tags to get any layout you want. Needless to say, it will not be affected by a recompilation of the DQL. Another big problem with the DFW DQL, was that one lost the straight forward way of exporting data from a DQL that one had in DFD. Another "quick fix" was created, this time the DQL export function. It was not very well implemented, so it was never extensively used, but we cleaned it up in 7.2 and now it actually works quite OK. So what we do in 7.5 is simply to add an exception to the exception: HTMLPRINT and TEXTPRINT. You use them instead of a file name in DQL export and we do the rest. for CUSTOMERS; list records CUSTNR; CUSTNAME; CUSTADDRESS; CUSTPOSTNR. end export to "TEXTPRINT" . .form header CustomerNr Name Address ---------------------------------------------------------------------------------------------------------------------- .items @f[1,1] @f[1,2] @f[1,3] .form trailer ----------------------------------------------------------------------------------------------------------------------- .end This will result in a simple text list like DFD, useful for simple lists, and they will dynamically format to your page size... Then over to the exciting bit. You can also format your print as dynamic html. for CUSTOMERLETTER; list records any CompanyRegister Letterheader ; any CompanyRegister LetterFooter ; letterbody. end export to "HTMLPRINT" . .form header .items @f[1,1] @f[1,3] @f[1,2] .form trailer .end Here we export 3 Memo fields that contains preconfigured HTML. LetterHeader and LetterFooter is stored in the company details and is reused for any letter that is written. LetterBody is edited in the correspondence from and is inserted in the middle from the CUSTOMERLETTER table. And the result you see below. This is just a simple implementation of this functionality, the sky and your imagination is the limit :-)

Published: 30/04/12 - 09:04:31 (Amanda Higgins)