Dear Tim,

> If you really want an accurate scrollbar, then create a temporary table with
> CREATE TEMPORARY TABLE AS with a dummy row number position, update the
> temporary table with row positions, and then create a descendant TEDBTable
> component that turns on accurate scrollbars by overriding this method:
>
>           function IsSequenced: Boolean; override;
>
> to return True.  Then, just override these methods:
>
>           function GetRecNo: Integer; override;
>           procedure SetRecNo(Value: Integer); override;
>
> so that they access your special row position column in the temporary table.
>
> If you find the performance acceptable, then you've got a solution.

CREATE TEMPORARY TABLE will:
1) not produce Sensitive Result
2) it's extacly the same a QuantumGrid does and maybe slower.

You can do/calculate it at runtime(engine level ?) like NexusDB does!
Please don't make it switch to NexusDB just for this!

You must respect what your customers wants else you force gonna loose
them. Some of your customers care about this, some don't, some haven't
even switch to EDB in order to see this issue.

I just only tested Nexus, i imagine if i test other RMDBS i would find
the RecNo support too.

The decision is yours. I don't want to loose or have unhappy customers
for a silly issue so i think you do the same for EDB.

Please don't take it wrong, i really love EDB and the work you do
but i want my customers too!

Thank you

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

Michael,

I made a decision on this before ElevateDB was released, and that's a
decision that I'm more than happy to live with.  I also have no interest in
implementing something akin to what NexusDB has, which amounts to nothing
more than walking rows and counting them, thus exhibiting terrible
performance in all but the smallest of datasets.  There's only two ways to
do logical row number support with BTree indexes - like DBISAM does, which
kills the update performance of indexes, or the way NexusDB does, by walking
and counting rows, which kills read performance.

There are some other options, but I'd rather not comment on them publicly at
this time since they are simply ideas that have no chance of seeing
implementation for several months, at the very least.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim,

> There are some other options, but I'd rather not comment on them publicly at
> this time since they are simply ideas that have no chance of seeing
> implementation for several months, at the very least.

Another database which supports RecNo is Accuracer and it seems very
fast. Anyway, thats not the point to find other products with RecNo
Support.

I think there is a solution out there that you can implement.

You may understand that we build database applications for our customers
and we must provide them what they want in order to keep develope
database applications.

Since i'm your customer and my customers doesn't report to you i must
forward my customers requests to you. (Since i'm using ElevateDB)

Despite that my personal opinion is that i hate not to have accurate
grid scollbar support (aka recno), it's also my customers opinion too
so i can't ignore it!

I understand your point about slow inserts and updates using statistics
but since i think everyday that everything is possible i insist that
you can implement a solution which it will have a only small penalty.

Tim, you're a brilliant man, you have a superb knowledge about databases
and you can do it! I believe in you! (You already prove it with the
creation of the most powerfull RMDBS in the world = ElevateDB)

I'm not try to *lick* you as we say here in Greece
but simple that's the truth!

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

Michael,

<< Another database which supports RecNo is Accuracer and it seems very
fast. Anyway, thats not the point to find other products with RecNo Support.
>>

Yes, especially since I already wrote one about 10 years ago called DBISAM.
 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.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Charalampos Michael" <chmichael@_-_no_-_creationpower_-_spam_-_.com> wrote
in message news:87D18D2C-2CB2-4729-81CB-FDEF8A1A72C7@news.elevatesoft.com...
>
> I think there is a solution out there that you can implement.

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.

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.

HTH
Rita

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.

Regards,
Michael



Charalampos Michael wrote:
> Dear Tim,
>
>> There are some other options, but I'd rather not comment on them
>> publicly at
>> this time since they are simply ideas that have no chance of seeing
>> implementation for several months, at the very least.
>
> Another database which supports RecNo is Accuracer and it seems very
> fast. Anyway, thats not the point to find other products with RecNo
> Support.
>
> I think there is a solution out there that you can implement.
>
> You may understand that we build database applications for our customers
> and we must provide them what they want in order to keep develope
> database applications.
>
> Since i'm your customer and my customers doesn't report to you i must
> forward my customers requests to you. (Since i'm using ElevateDB)
>
> Despite that my personal opinion is that i hate not to have accurate
> grid scollbar support (aka recno), it's also my customers opinion too
> so i can't ignore it!
>
> I understand your point about slow inserts and updates using statistics
> but since i think everyday that everything is possible i insist that
> you can implement a solution which it will have a only small penalty.
>
> Tim, you're a brilliant man, you have a superb knowledge about databases
> and you can do it! I believe in you! (You already prove it with the
> creation of the most powerfull RMDBS in the world = ElevateDB)
>
> I'm not try to *lick* you as we say here in Greece
> but simple that's the truth!
>
> Thank you

> but simple that's the truth!

The cost of having RecNo to performance is The Truth.

Accurate and timely data access is The Truth.


Walter

and in the Green corner, is Tim Young. Wearing the red boxer shorts,
weighing in at ____ pounds.
and in the Blue corner, is Previous Discussions, in the white shorts,
weighing in at 0 pounds.

Looks like it will be a quick fight.

Michael

<<For what it's worth, IMO no serious RDBMS will provide RecNo.>>

Actually EDB includes three products:

1. SQL Engine
2. DAC components
3. DBManager

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. As far as I understand EDB DAC  is deeply integrated to the engine, the
components do not store result sets, the engine does that for them.  (This is exactly the kind of functionality I was looking for desktop/
briefcase apps, this would be a big big bonus for us. ) You are right  that RecNo support normally has nothing to do with the Engine. But
in this unique architecture, where DAC functionality is already partly implemented  within the engine, there is no other way to  do it than
inside the engine.    

<<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. >>

What you are suggesting here is to use an other DAC with the standard "separate  Engine & DAC" architecture. But why would anyone
want to do that when there is already a good and fast DAC provided by the vendor who knows the engine better than anyone else ever
will?   (Unless middletier is what you really need.)


Tim,

I am trying to be as not annoying as I can - though I might be failing -  but I keep hoping you can see the good intention behind my
not dropping the subject. I just keep trying to find you an angle, which might help you to look at this question in a way you could not see
it before. I can only guess, but it seems that in your mind you are creating an engine with some additional stuff like DAC and
DBManager. It might be useful to rethink it from the viewpoint of the DAC, as if you were making a separate DAC product for an Engine
created by someone else.       

I guess the main technical conflict is with "sensitive result sets".  This is a great functionality, kind of same on the Engine level as cloning
on the DataSet level with some other DAC's/memory  datasets)  The problem  is  that at the moment it  is INSTEAD OF simple none
sensitive yet updateable resultsets. Which is the functionality missing  from EDB DAC, but is a basic functionality of all other DAC's . If
there is an easily implementable solution not messing up  the current logic of EDB it could be something you have suggested for me on
the dataset level, but done on the engine level for updateable views/temp tables . But the full blown solution may  not be much further
from that:    

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. 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. If we had this, plus updateable views (which as I understand is
already on it's way) any situation could be handled smoothly. Small/infrequently updated  tables can have RECNO SUPPORT turned on,
and  the rest can be stored WITHOUT RECNO SUPPORT and displayed and edited through updateable views WITH RECNO SUPPORT. So
for large tables the RecNo support would take place mostly in memory instead of disk and  only for the small portion queried at the time.
The only case disk would be involved is when the resultset returned by the view is large enough not to fit in to the memory. But this is
something to watch out for during optimization anyway.

Please forget all the history of this subject  for a while and consider it as if you had just started planning the whole thing! I really think
there is a solution here, this really could be  the way to go.

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. You won't be happy with this solution in EDB,
believe me. The question is: how do you know which record you are on if you do Locate? Firebird's
DAC does locate only by downloading all records to the client until the match is found. EDB has a
much better solution, I believe. Accurate scroll bar is not a feature of any SQL Server I know,
except maybe Nexus, which I'm not sure about. Without server support, this feature is meaningless,
because you will need to download records in order to count them if you are implementing a DAC on
your own. The only engines that support that are usually navigational engines, such as DBISAM,
Paradox, Absolute Database, etc. Tim's move was clearly towards SQL server from navigational
engine, so...

Sincerely,
Michael