I always wanted something build into DE;

1. Auditing who opened the form in user view last, who ran a DQL last
2. Status import does not show enough information
3. Windows API integration without us building DLL

Hi Arul.

“Auditing – who opened the form in user view last, who ran a DQL last”

DataEase has to lean towards simplicity, ease of use and, RAD. An Audit system is not something they I want as a standard part of DataEase ever.

DataEase is a development tool which means that it should be easy to make a system like this, and it is.

Especaially in 8.6 where we have got anylookup().

You can simply make a DQL to use to open your documents.

define “retval” text .

enter a record in Audit
User := current username ;
Time := current time ;
date := current date ;
Document := data-entry field1.
retval := documentopen(data-entry field1) .


execute it like this on a button or in a derivation etc.

ExecDQL(anylookup(“DQLStore?DQLID=002”,”DQL”),”MyDocumentToOpen”) .

As a development tool we need to focus on functions and functionality that together make a powerful and easy to use programming too because programmers need to put the lego together.

It is the PeteEase way of doing thing to add big and complex “functionalities” that can’t be used in programming so if they don’t fit you are stuck.

Programming is about flexibility for the developer to create the features the way he wants and our job is to make that as easy, quick and last but not least – flexbile and changeable as possible.

We should never make a function or functionality if you can make it yourself with the building blocks available. Then we should simply make a sample or module that people can use in their apps.

Programming is like the rainbow. You should only make base colours as the rest can be made from mixing them.

“Status import does not show enough information”
True, but that is because they are reports i.e. someone had decided what is interesting to report on without really understanding the product. One of my pet hates are aggregation. You should always leave data in their original form as you never know what is interesting in 6 months, 1 year, 10 year, 100 years time. If you aggregate you have already made a decision to exclude statistical information for the future.

One omission in Tables (fields) for instance is if a field is virtual. For some reason that was not deemed important by “Pete”.

When you consider the consequences of virtual fields on an application if poorly or wrongly made it is critically important to be able to find them when you analyse an app but you can’t because you have now way to find it besides going through your app and click on each field.

We have added this now, but we can’t add things as we realise its missing it should be native.

On top of this Status Reports are not “fresh” they are generated.

In 8.6 you are able to query prism directly and get all the information on tables etc.

Status reports is not something we should make, we should just give you the opportunity to query this information in real time from the “horses mouth”.

“Windows API integration without us building DLL”
Not entirely sure what you mean with this. Any tool like DataEase is in fact a “Windows API Integration without you building DLL”.

If you want to have full access to all the functions in Windows directly you need to make DataEase and not an app in it ;-)

You can call a lot of Windows functions directly via CDF interface but windows is much more complex than simply calling functions.

You have functions that will return information and then you have functions that will set things in motion etc.

The way we deal with windows is that we add our own functions that cover the areas we think is interesting for our users.

What is it you are missing that you think you will solve by having full access to Windows API?

The way I work is that I never do what the customers ask me. But I always store away the fact that they asked me and what they asked for.

Very often the question is not formulated the “right way” but the underlying requirement is real i.e there is something “missing”.

When enough people ask me the “same” question in different ways I form an opinion on why it is asked.


Based on your email (all of it) and previous requests and ideas I have had myself I can say that the problem is CDFs i.e. hoe to make your own functions that you can use everywhere in your app.

The reason we have made so many functions in 8.5 is that functions are “non invasive” in DataEase hierarchy i.e. you can implement them and they will be useable everywhere from day one without any need to change anything else like parsers/gui etc.

you can use a function on a button, in a derivation, in DQL, OML anywhere you can write a number you can use a function.

1+1 1+MyFunction()

When we make functions we often just use DQL engine internally to do the job and return the result.

Why re-invent the wheel?

So that is what we should add in DataEase

CDFs which are really just DQLs that you can call directly from anywhere by an assumed name.

Then your audit document open could be called that.

AuditOpen(“MyDocumentname”)

instead of:

ExecDQL(anylookup(“DQLStore?DQLID=002”,”DQL”),”MyDocumentToOpen”) .