Okay, I had read the part about performance may be increased 2x to 5x's but.....!!!!  In some of my data bases the procedures are taking hours instead of minutes.  This just does not make the move off Windows XP a viable option.  I noticed that the CPU was never higher than 13% of capacity for any of the applications in LegEasy4DOS.  Is there a way to utilize more of the computer resources for the application to speed up these processes now having to go through so much code?  Are there any other options?

LegEasy4DOS is emulating DOS to run 16 bit core of DataEase. The target for LegEasy4DOS is networked applications.

To measure performance is very hard as it depends on what is happening. We have found that LegEasy4DOS offer massive improvements when running in a network, when it can be slower running on a local drive.

This is due to the emulation.

In projects where we have experienced the same as you are describing we find that the problem is due to a massively unnecessary processing that you get away with in native DataEase on a local drive. 

Typically the problem is due to wrong use of indexing etc.

LegEasy4DOS is not a wonder cure, but a way to allow users to move forward with DataEase for DOS.

When running old software in a modern environment there will always have to be trade offs and reworking the worst DQL's will be a part of that.

If you are running a single user DosBox might be an alternative and it might or might not be a little quicker as it doesn't use locking etc (which is the main problem with using it at all) but that too is emulation so most likely you will experience the same problems.

How is the wrong use of indexing?  How can I make my DQL's run better?

The "performance problems" in LegEasy4DOS has for many been a blessing in disguise.

We have clients that has been running big DQLs on standalone computers over night simply because it would't complete in time (or at all) when run in the network.

So when they start using LegEasy4DOS where the Network performance can be much better than "native" DFD but the standalone performance can be poorer they suddenly got a problem.

DQLs that used to finish in 3-4 hours suddenly took more than double that time etc.

But a DQL should "never" take 3-4 hours in the first place. Not one you run daily at least.

The problem with a lot of DataEase application is that they are just "developed" as the sticks fall. On need do to an aggregation or an update and one quickly write a DQL to do it, then added limitations etc are need later and the DQL is "augmented" again and again.

All this works fine when the data set one run on is a couple of thousand records etc, but after a while one get 100s of thousands if not million of records in a table and things change.

When you run a DQL in DataEase the entire scope of that DQL is kept in memory which makes it very efficient until you reach the memory limit which for DataEase for DOS is sadly quite small in today's meassures - 16 MB.

When this limit is reached DataEase need to start doing its own memory swapping to disk. This slow down everything enormously. Then imagine that the memory needed for your DQL is like a couple of GBs and you realise why things go so slow...

So you need to limit the scope of the DQL and that means that you need to limit the data set it need to work with.

1. DataEase only use index on the first column in a WITH statement and in a RELATIONSHIP definition. So this is the critical point. WHat you do in the fist stage is whats going to make or break you.

The first limitation need to limit the scope as much as possible!!!

We have seen big DQL that process 2+ million records that is like this;

for MyTable with YesNofield=Yes and Name not="John" and SurName not="Smith" etc etc and CreationDate>current date-14 ;

A DQL similar to this took 6 hours to run and it was needed to run every day.

the problem was 2+ million records in table and more than 80% of them at YesNoField=Yes ....

By simply rewriting it to

For MyTable with CreationDate>current date-14 etc. 

This DQL ran in less than a minute!

So the important thing is:

1. Make sure the first column in any relationship gives the best limitation (lowest hit) and that it is indexed.
2. Prioritise the stages in that order so the most limiting first and then the second best etc.
3. It is no point in over indexing either, every field you use after the first stage don't use index anyway (can't obviously) and over indexing slow down the modification,deletion and insertion of your table.


Sum of, Count of etc.

ANother big problem is the unrestricted use of vritual fields with sum of,count of etc.

The same rule goes here.

If you use sum of, count of etc in a DQL you need to make sure that the relationship is optimal and the first column in the selection statement give a optimal hit with index etc.

You can accomplish ENORMOUS performance enhancements in DataEase from DFD 2.x to 8.5 by doing things the right way, but DataEase will let you get away with anything so you need to know what you are doing and then do it as the automated DQL's etc will not take any of this into consideration.

Might be right but 99.99% of all DQLs start with FOR simply because that is what the DQL Editor suggested.

I think maybe you got this upside down Ihor. Non programmers don't have a relationship to FOR etc. but programmers do so for programmers the syntax in DQL is "horrible" but for normal people it is kind of logical.