Michael,

<< Both Table and Query. >>

Actually it's quicker just to simply count up to the current position.  The
maintenance alone on such an index is very time-consuming since it has to be
constantly synched to the current state of the table by rebuilding portions
of it.

--
Tim Young
Elevate Software
www.elevatesoft.com

AJ,

<< Ok why not give a list of future features that will be effected and how
bad. Then people can decide if 3 state scrollbars are really that bad. >>

I've already mentioned a big one - having versioning of the index keys for
multi-versioning in the transactions.  Also, more esoteric locking in the
indexes for greater concurrency.  When the entire path from the root to the
leaf of the index tree needs updated for every insertion or deletion into
the tree, then the entire path must always be locked.  Finally, fail-safe
writes need to log all I/O before actually applying it to the table, thus
any decrease in the amount of I/O makes fail-safe writes more and more
doable.  And fail-safe writes mean, barring complete hardware failure, no
more corruption or repairing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Stefano,

<< I am waiting for the first release.....(I vote for remove stat). >>

Thanks.

<< Excuse me for my elementary concepts, but my english is so bad that I'm
not sure that you understand me, sorry >>

I think I understood what you said - you were asking whether the record x of
x type of display would still be possible when using TEDBTable components.
I replied that it isn't impossible yet, but it might be if we remove the
index stats like we're discussing right now.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> Finally, fail-safe writes need to log all I/O before actually applying
> it to the table, thus any decrease in the amount of I/O makes fail-safe
> writes more and more doable.  And fail-safe writes mean, barring
> complete hardware failure, no more corruption or repairing.

Well, to me that sounds like a great reason to dump the stats.

Regards,

SteveG

Given the option I would choose fail-safe writes over stats.

Chris Holland


Tim Young [Elevate Software] wrote:
> AJ,
>
> << Ok why not give a list of future features that will be effected and how
> bad. Then people can decide if 3 state scrollbars are really that bad. >>
>
> I've already mentioned a big one - having versioning of the index keys for
> multi-versioning in the transactions.  Also, more esoteric locking in the
> indexes for greater concurrency.  When the entire path from the root to the
> leaf of the index tree needs updated for every insertion or deletion into
> the tree, then the entire path must always be locked.  Finally, fail-safe
> writes need to log all I/O before actually applying it to the table, thus
> any decrease in the amount of I/O makes fail-safe writes more and more
> doable.  And fail-safe writes mean, barring complete hardware failure, no
> more corruption or repairing.
>

If the fail-safe applies to fileserver mode as well then no stats becomes a no brainer (DBISAM is good but I do have to do repairs occasionally)

Roy Lambert

> Given the option I would choose fail-safe writes over stats.

This decision keeps getting easier and easier

Tim,

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:20C40701-E4BF-4F91-BA73-986B900695F3@news.elevatesoft.com...
>
> The effect of the index statistics on DISTINCT operations is minimal,
> unfortunately.   The only thing that DBISAM and ElevateDB don't do with
> regard to distinct processing in terms of nice "shortcuts" is use existing
> indexes, which is what I believe SFD does.
>

Well you asked for feedback and you got it, most peeps say dump the stats.
Rita

I agree.  I will take performance and stability over stats.  I use DevEx
Grids so the scroll bar is not an issue.

Bill

I vote for working scrollbars...it would be a nightmare to replace every
descended DBGrid in my apps