Leslie,

<< Tim, you already have a working solution, you already know how to
implement RecNo support and I am going to assume  that it can be adopted for
EDB. >>

Probably, but that's beside the point.  I've already noted *many* times that
the decision to not include logical row number support was due to
performance, and not because it couldn't be done.

<< You seem to be kind of obsessed with the "RecNo support causes slow
update performance on large datasets"
problem. Why do not leave this in the hand of the user? If there was a
"WITH/WITHOUT RECNO SUPPORT"  parameter for CREATE/ALTER TABLE/VIEW/DATABASE
the user could decide what is best. >>

It's not that simple at all.  The format of the indexes would need to
change, along with almost all of the navigational code. Given that amount of
other features that need implemented, this is simply not an important
feature for us right now.  As I told Michael already, I've got some ideas on
some ways to deal with it, but nothing that will see even a test
implementation for quite a while.

--
Tim Young
Elevate Software
www.elevatesoft.com

Leslie,

<< For other engines these three usually come from different vendors. It is
a bonus that EDB includes all of them. But  most (most likely all) other
delphi DAC components handles RecNo on the client side in order to properly
support grid components. So in this regard EDB DAC is missing an important,
one might even say basic feature. >>

You are comparing apples to oranges here.  In most cases these other
front-ends require that all rows in the result set be fetched into a static,
client-side memory dataset in order to number each row.  ElevateDB provides
*live* access into tables and sensitive result sets/views, and therefore
must be able to dynamically calculate a logical row number *quickly* in
order to provide such logical row numbers.  The only way to do this with
B-Tree indexes is to store statistics in the indexes that allow you to
aggregate the row position as the index is navigated.  However, these same
statisitics need to be updated during every index update, and will require
updates to propogate up the index tree to the root node for *every single
update*.  That's a lot of extra I/O in any busy application, and that hurts
performance and concurrency.

Remember, for most database engines/servers, there is no such thing as
opening a table directly or browsing a server-side sensitive result set or
view, seeing all changes made by other sessions immediately.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

You do not need to protect your decision, because it is your call not mine.   

Please, please, please read it again and try to understand it, because you did not! You are telling me things I already clearly understand
about the technical part ...  about your being capable of doing it ... sensitive datasets ... and frankly there is no way to counter the "too
much work required part", it is the trump ace. But some day maybe you will have the time or you just get tired of this issue which
makes you do it, and  there is something above you have missed and might be useful. The design and programming practice is there,
how EDB  could be used with the minimal penalty yet having accurate scrollbars for most situations.  

The data needs to be displayed  in  grid and edited many times does not qualify for sensitive result sets, and that is the only thing you
seem to care. Whenever this is the case it becomes difficult to work with EDB DAC components. I think you should try  to think over how
EDB can be used if you take sensitive resultsets out of the picture.     

Michael Baytalsky wrote:
> Leslie,
>
>> For other engines these three usually come from different vendors. It
>> is a bonus that EDB includes all of them. But  most (most likely all)
>> other delphi DAC components handles RecNo on the client side in order
>> to properly support grid components.
> Examples, please. The way Firebird's DAC support recno is by executing
> the same query several times including once with count(*) in order to
> get RecNo. ...

What do you mean by "Firebird's DAC" ?

--
Aage J.
If this is getting to far off topic, we'll just let this subthread die...

Dear Walter,

>> but simple that's the truth!
>
> The cost of having RecNo to performance is The Truth.
>
> Accurate and timely data access is The Truth.

I don't think so ... The truth is that RecNo will have
a perfomance hit and the perfomance hit depends
on the implementation of the method used.

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Dear Tim,

> Yes, especially since I already wrote one about 10 years ago called DBISAM.
>

Well, don't forget Eryk which helped too.I can't don't forget him and
his aggressive attitude in some cases.

Oh boy, i miss him and Ole too ...

> It's not that it can't be done, it's that there are significant
> downsides to it when you start to get into the 1 million+ row range.  It may
> not be your personal experience with your customers, but a lot of ElevateDB
> customers have customers with very large amounts of data, and we cannot
> afford to give up raw performance for the sake of something as petty as
> scrollbar display.  When it comes down to it, the choice is rather easy.

Yes, include both index methods
(as i can see leslie proposed that in a following answer)

Then you have all your DBISAM customers happy and give them
a reason to upgrade to EDB = $$$ for your company.

Anyhow, i get used to have upgrade/changes of DB formats ...
From Paradox->DBISAM v2->v3->v4->EDB v1->v2

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Dear Rita,

> Michael the solution is out there try rolling your own.
> Tims taken care of the engine so its fast have you
> even tried switching off the Devx grid scrollbars and
> using the Tscrollbar component from the standard
> vcl page. This is what it says in the help file.

Apparently you haven't tried QGrid in with real world data over
eg 20.000 records.

> The scroll bar component creates a scroll bar that you can use to scroll the
> contents of a window, form, or other control. In the OnScroll event handler,
> you write code that determines how the control behaves when the user moves
> the scroll bar.
> The scroll bar component is not used very often, because many visual
> components include scroll bars of their own and thus don't require
> additional coding. For example, TForm has VertScrollBar and HorzScrollBar
> properties that automatically configure scroll bars on the form. To create a
> scrollable region within a form, use TScrollBox.

Are you serious ? (as i can imagine not ...)
Why to reinvent the wheel since QGrid does the same ?

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Dear Michael,

> For what it's worth, IMO no serious RDBMS will provide RecNo. Having
> switched
> to Firebird and Oracle I miss many of DBISAM's features. I'm not sure
> how they did it in Nexus but it does incur penalty. Therefore, I think your
> best bet would be middle tier, where you could read the whole dataset into
> memory fast and then do whatever you like with it, including having it
> sorted
> filtered and numbered. This is by far the best approach from the pow of
> scalability and user experience. I'd say if you demand WAN access to data,
> then middle tier should be a default option.

The idea of EDB is to make better than DBISAM and not a crippleware ...

There isn't need to use any Memory Dataset while using QGrid.
It does the same thing!

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Aage,

<< What do you mean by "Firebird's DAC" ? >>

DAC is short-hand for Data Access Components.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim,

> It's not that simple at all.  The format of the indexes would need to
> change, along with almost all of the navigational code. Given that amount of
> other features that need implemented, this is simply not an important
> feature for us right now.  As I told Michael already, I've got some ideas on
> some ways to deal with it, but nothing that will see even a test
> implementation for quite a while.

As i said you're a brilliant guy and you proved that on our e-mail
conversation ...

So, it's a matter of time EDB to be the best RMDBS out there.

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr