Leslie

You should read the thread in this ng titled "Some Feedback Required"
dated 2006-09-25.

You will see that Tim specifically explained the issues and asked us
to vote.  This may help you to understand why Tim cannot now change
direction.

Malcolm

Roy,

<< Out of interest would it be possible to approach it from the opposite
direction. Rather than what changes are required to ElevateDB to make a
standard dbgrid show the button at the "correct" position; what changes are
required to a dbgrid to get it to show the button at the "correct" position
regardless of table/index type. >>

The problem is that the standard grid, and most descendants or replacements,
rely on the TDataSet.RecNo property to determine the logical row number in
relation to the TDataSet.RecordCount property.

Also, we can estimate the position of a row based upon the active index, but
I'm not sure such a thing would work in practice because the scrollbar
positioning would sometimes jump around a bit in a seemingly random fashion
when the estimates are off a bit.

--
Tim Young
Elevate Software
www.elevatesoft.com

Leslie,

<< It is your code. you are the one who can estimate what it takes to change
it. >>

I don't need to estimate it - I've done it already in DBISAM and I
specifically removed it in EDB because it causes the database engine to
perform poorly with a large number of rows.  It takes a lot more I/O to
constantly update the statistics in the indexes.

<< I am just tyring to introduce  ideas/ views you may have not considered
yet. >>

I've gone through this in a lot of detail already.  Remember, it's my
full-time job to solve these issues.  If there were an easy way to do it,
then you'd see logical row numbers implemented in every database engine out
there.  Most database engines/servers don't even allow you to browse a live
table, rather they require you to fetch the rows into a client-side cache.
That is why it may appear that certain products offer accurate logical row
numbers - the rows are simply in the equivalent of a TList, making numbering
easy.

<< By my understanding adding the ability to work with different type of
indexes does not hurt the exisitng code
as it is basically adding something like this to some places where indexes
are involved: >>

This is not correct.  Any changes to the code could possibly hurt any number
of other portions of the code, unless you're suggesting that I copy and
paste the existing index navigation and updating code for each index type.

<< I my understanding this does not effect the stability of the current
code. Though the amount of work and time required to implement and test some
of the index related code to work with different kind of indexes can be much
more than implementing this. It is a question of design. Eg with PostgeSQL
the user can add costum index formats without any change to the engine. >>

Does PostgresSQL offer logical row numbers on a live table ?  If not, then
what you're talking about has no bearing upon the topic at hand, other than
to point out that PostgresSQL offers multiple index formats, none of which
provide the functionality that we're discussing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>The problem is that the standard grid, and most descendants or replacements,
>rely on the TDataSet.RecNo property to determine the logical row number in
>relation to the TDataSet.RecordCount property.

Bummer

>Also, we can estimate the position of a row based upon the active index, but
>I'm not sure such a thing would work in practice because the scrollbar
>positioning would sometimes jump around a bit in a seemingly random fashion
>when the estimates are off a bit.

That sounds highly suitable for a Microsoft platform and certainly suits my style of programming

Roy Lambert