In DataEase 8 we try to break stuff down into simple functions so you can use it as LEGO bricks and make whatever you like. Simple but powerful. When developing DG3 we looked at DFW, DataEase 7 and WebPublsiher as standards of how "not" to do things. In DataEase 8 we have tried to bring some of this methodology back.

A DG3 application is a compacted powerpack that do exactly what you want it to exactly how you want it and when you want it. For all of you that has been working with DFW, that is not exactly how you would put it ;-)

OML has been a mystery to most and in our opinion that is a good thing. In 8 we have tried to extract the essence of what OML has or would have been used for and put that into simpler functionality, more readily accessible to normal users. 

We have already addressed manipulation of fields and objects, but one thing that you have in abundance in DG3 but basically is very "awkward" in DFW is to manipulate data and running procedural logic with a low "footprint" so to speak ;-).

Some of us get a fussy an happy feeling when we see a "chain menu" execution in DFD, but very few have warm feelings towards the flashing and flickering of chained DQL's in DFW.

Because of the way DQL is implemented in DFW it has been very hard to get round this problem, but with inspiration from DG3 we now think that we have cracked it.

We simply implement a DQL interpreter that circumvent the "traditional" way DQL's have been executed in DFW. The problem and misunderstanding around DQL is that it is an "advanced report/procedure", it is in fact rather the opposite. In DG3 we use interpreted (everything is interpreted in DG3) everywhere. Update this, delete that etc.

So now we do the same in DataEase 8. Enter ExecDQL(), MemoExecDQL() and FileExecDQL().

ExecDQL and the others is not reimplementation of Run Procedure or Document Open, these functions are live ammo.

Format: ExecDQL(ScriptString(255),DataEntryString1,DataEntryString2,DataEntryString3,DataEntryString4,OutputFile)

ScriptString: DQL script up to 255 characters long.
DataEntryString1..4: Any normal data-entry value but will be transferred as string, DataEase automatically translate between formats. Will be referenced internally in Script as data-entry field1 through data-entry field4.
OutputFile: BLANK if no output is wanted or filename with path for export/simplified print. We are looking into making a simplified "outputbox" as destination too.

Returns:  Error message if you script is wrong (We recommend that you test the script out in the normal DQL editor etc before pasting it into here ;-)) or the value allocated to the internal variable DQLReturn inside the DQL. (Remember this is DQL as as function...)

Example 1:
ExecDQL("modify records in Cutomer with customernr = data-entry field1 ; customername :=data-entry field2 .",customernr,customername,"","",outputfile) 

Obviously 255 characters will be way to little for the more advanced DQL's, so this is where the two twin functions come into play.

MemoExecDQL() will do the same and have the same parameters as ExecDQL() with one big difference, the script reference which will be a memo field.

Format: MemoExecDQL(ScriptMemo,DataEntryString1,DataEntryString2,DataEntryString3,DataEntryString4,OutputFile)

Example 2:
MemoExecDQL(lookup MyScripts ScriptMemo,customernr,customername,"","",outputfile) 

And last but not least, for those of you that don't trust Memo's and prefer good old text files, you can simply use FileExecDQL().

Same as MemoExecDQL() but it will reference a textfile instead.

Format: FileExecDQL(ScriptFile,DataEntryString1,DataEntryString2,DataEntryString3,DataEntryString4,OutputFile)

Example 3:
FileExecDQL(concat(GetCurrent("AppPath"),\scripts\UpdateTrigger.txt),customernr,customername,"","",outputfile) 

Whisper...

With the new interpreter we will also be able to "surgically" implement DQL events in Forms like OnOpen(),OnClose(),OnNew(),OnUpdate(),OnDelete()..... might this be conceived as triggers? Wait and see...