Hi Nadya,

>I read your messages about no benefit of deleted() tag. I read the thread started by Andris Moore (may misspell his name). Anyway, currently we have deleted() tag in all our tables. Query speed is far from ideal, but we're working on it. Set deleted is on in the main program and Base form class Load.

>I may try to make the experiment, you suggested, on the smallest database (RI).

The negative effect of the DELETED() tag is the biggest on large tables. having a 4 Mln record table would significantly slow down opening the table with SET DELETE ON, esspecially on a network.

Just try:

SET DELETE ON
USE MyLargeTable

You'll notice that it takes a while to open the table (especially on a network) because it has to load about the whole DELETED() tag first.

It may be wise to make a copy of the data, remove the DELETED() tag and test performance again. I'll bet you'll see some significant improvements in performance.

>TranMstr describes transactions and PropMstr describes property. PropMstr is a parent and TranMstr is a child. For MA TranMstr has about 5mln. records and PropMstr about 4 mln.
>
>So, are you saying, that
> scan for condition
> endscan
>
> and
> scan
> if condition
> endif
> endscan

> is the same? I'm not sure.

This only counts for FOR clauses that are not rushmore optimizable. The only other overhead is the IF statement. The IF statement does not require that much of CPU resources so, the delayd time should lower than one or two seconds for 4 mln iterations (on my AMD 750 about 0.6 seconds)

> For CT your solution took ~2min. and it has 3mln/2mln records.
> If I would scan 3mln records, I think, it should take longer, than 2min.
> Anyway, I may run couple of tests on Monday, if I'd have time.

CT ?? Anyways, yes testing is the best way to optimize speed.

Walter,