Rastislav,

If you use a memory dataset like TClientDataset, you can use the grid of your choice. Of
course large datasets may cause speed and memory problems  too.


Leslie

"Tim Young [Elevate Software]" wrote:

Michael,

<<I've explained this several times already.  You can't just add this in the
code, it is something that requires the index format to support it, and we
have no intention of changing the index format any time soon.>>

Maybe there is an other approach then picking just one way to do it. Eg PostgrersSQL
supports different index formats, and allows to pick the best index type for every index.
The current design od EDB may not allow this, but maybe you can come up with something
similar with v3.0?

Leslie

Correction:

Maybe there is an other approach BESIDE picking just one way to do it...

Tim, Leslie

Tim, I read all discussions about this problem and I understand. But unfortunately, I want
show
table with lot of unicode records in DBGrid with accurate scrollbar. I would be very like
use DBISAM
or EDB, but it see I must find other solution.  
Best wishes to your great work !

Rastislav

Thank you Leslie.

Rastislav

Leslie,

<< Maybe there is an other approach then picking just one way to do it. Eg
PostgrersSQL supports different index formats, and allows to pick the best
index type for every index. The current design od EDB may not allow this,
but maybe you can come up with something similar with v3.0? >>

There's more to it than that.  There's a huge amount of work involved in
retrofitting EDB to be like DBISAM in this respect, and it would be
extremely disruptive to the code base at a time when EDB is maturing quite
nicely.  If there were some huge payoff to such a chance, then I might
consider it.  But, scrollbar display does not fall into that category,
especially since we'll still have the same issues with filters and logical
row numbers that we have with DBISAM.

The bottom line is that this decision was made when we released ElevateDB,
and we're going to have to live with the consequences.

--
Tim Young
Elevate Software
www.elevatesoft.com

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.

Are there grids out there that do this apart from when the data is fully loaded?

Roy Lambert

Tim,

<<There's more to it than that.  There's a huge amount of work involved in
retrofitting EDB to be like DBISAM in this respect, and it would be
extremely disruptive to the code base at a time when EDB is maturing quite
nicely.  If there were some huge payoff to such a chance, then I might
consider it.  But, scrollbar display does not fall into that category,
especially since we'll still have the same issues with filters and logical
row numbers that we have with DBISAM.>>

It is your code. you are the one who can estimate what it takes to change it. I am just
tyring to introduce  ideas/ views you may have not considered yet. 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:

if IndexType = itWhatIsAlreadyImplemeted then
 // Do what is already implemetned
else
if IndexType = itAnOtheIndexeType then
// Do the same thing with this type of index
...

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.  (I am not trying to compare the products, they were designed
obviously with  different goals in mind.)

Just to make sure you understand my motives: I am not here to question your decision, it
is not my business. There just may be things you have not quite considered througly and
can improve the product ....

Leslie       

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.

Are there grids out there that do this apart from when the data is fully loaded?>>

Very good question! I was thinking about the exact same thing, though a bit more generally
as I need to fill  trees as well ... no solution yet, probably there is none at all.  I
only found workarounds with linear time cost groth.  

Leslie

Leslie


Trees! I don't know of any genuinely data aware trees. I presume you're using VirtualTree?

Roy Lambert