Dear Tim,
  My customers aren't happy about not having accurate scrollbars when i
  present to them a demo of new version of my application.

So i have 3 choices:
1) Go back to DBISAM v4 which it's not as powerfull as EDB and it's
   feature list is frozen. So i don't consider this.
2) Add Statistics to EDB in order to get accurate scrollbars which
   is the way to keep up my current projects to EDB.
3) Find another advanced DBMS which supports accurate scrollbars.

You can add some kind as optional to use statistics or not
as SQL Server has. If they made it then you can!

Eg, i have a table which i want accurate scrollbars which i don't
care to have them for another table and you can store the property
on catalog schema.

You already have the code ready and i don't think it's that hard
to port it into EDB.

I'm waiting for you comments.

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

Charalampos,

> So i have 3 choices:

Actually, you have a couple more than just those three.  If your tables are
not too large, you can use the DevExpress grid controls to read the entire
results set into the grid.  Once they are in memory, the positioning of the
scroll bars will show the actual position in the result set.

You can also use the TClientDataset component or any other in-memory dataset
to load the entire result set.  This will give you the same effect as the
DevExpress grid but you can continue to use your existing components.

--

---------------------------------------
 Terry Swiers
 Millennium Software, Inc.
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

Dear Terry,

> Actually, you have a couple more than just those three.  If your tables are
> not too large, you can use the DevExpress grid controls to read the entire
> results set into the grid.  Once they are in memory, the positioning of the
> scroll bars will show the actual position in the result set.

I'm already using QGrid and this is toooooooooo slow if you have many
records. (imagine on a slow network too or wan).

> You can also use the TClientDataset component or any other in-memory dataset
> to load the entire result set.  This will give you the same effect as the
> DevExpress grid but you can continue to use your existing components.

This is slower than loading all the record in QGrid.

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

Charalampos,

> I'm already using QGrid and this is toooooooooo slow if you have many
> records. (imagine on a slow network too or wan).

If you have large tables, then yes it can be slow.

With regards to that, make sure that if you have a remote connection that
you increase the read ahead buffer to at least the number of records that
are displayed initially in your grid.  Also make sure that you add a
Grid.BeginUpdate and Grid.EndUpdate around the open statement of your table
or query.  That can make a huge difference in the performance of the load
process.

--

---------------------------------------
 Terry Swiers
 Millennium Software, Inc.
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

Michael,

<< You can add some kind as optional to use statistics or not as SQL Server
has. If they made it then you can! >>

SQL Server statistics have nothing to do with the scroll bars.  It's an
entirely different type of feature.

<< You already have the code ready and i don't think it's that hard to port
it into EDB. >>

I'm sorry, but I've already had this conversation at least ten times since
ElevateDB was released, and I don't care to rehash it again.  If you'd like
my comments, use the newsgroup searching to find out what I said the last
time that you asked this question.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Terry,

> With regards to that, make sure that if you have a remote connection that
> you increase the read ahead buffer to at least the number of records that
> are displayed initially in your grid.  Also make sure that you add a
> Grid.BeginUpdate and Grid.EndUpdate around the open statement of your table
> or query.  That can make a huge difference in the performance of the load
> process.

I've already tried Begin/End Update/Controls. It speed up the process
but still it needs time to load and show the actual data.
(which making the application slow)

Anyhow loading all records into memory every time isn't a solution
as performance and resource perspective.

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

Dear Tim,

> <<  You can add some kind as optional to use statistics or not as SQL Server
> has. If they made it then you can!>>
>
> SQL Server statistics have nothing to do with the scroll bars.  It's an
> entirely different type of feature.
>
> <<  You already have the code ready and i don't think it's that hard to port
> it into EDB.>>
>
> I'm sorry, but I've already had this conversation at least ten times since
> ElevateDB was released, and I don't care to rehash it again.  If you'd like
> my comments, use the newsgroup searching to find out what I said the last
> time that you asked this question.

I've downloaded NexusDB and it has a option which turns on RecNo
Support. (aka accurate scrollbar) Can't you do the same to EDB ?

From their help:
- RecNo Support -
RecNo support is a special feature to accommodate correct positioning
with the thumbs slider on grids.

You can:
A) Calculate it at runtime
B) Store it inside indexes, just the RecNo! (much faster)

So how about adding only "RecNo" support (Option B)
without adding anything other ?

Thank you

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

Michael,

Storing RecNo is a performance killer. The more data you have in a table the more it costs. There is other way to do it, but it still effects
performance. I went down the same road you are on, Tim keeps saying there is no "OR",  just "XOR" for some reason we do not
understand, though he have explained already. I have not taken the time to go into the details because it does not change anything for
us.  

Tim,

I can understand your frustration about being forced into the same conversation time and time again, but you could look at it as an
extremely hard to implement feature request popping up regularly, which bugs some of your (real + potential) costumers a lot.

I have never in my life invested so much time and effort into a technology I wanted to introduce at my company. Not even close.
Precise scrollbar handling is a must with our costumers, therefore the lack of it is a show stopper for us. I have tested several grid and
tree components capable of caching and sorting to overcome this limitation, but it is always too slow. The only other way to do it is using
memory datasets like ClientDataset or KBMemtable, but with large datasets it is still too slow and there is always the memory to worry
about. Every solution  outside your engine kills the main reason what would make EDB special for us.  You seem to be concentrating on
the C/S usage of EDB, which is probably the way most of your costumers are using it.  We have applications used on notebooks and
PDA's which are not always online and synchronize the data through replication.  EDB offers not just an engine but also dataset
components  deeply integrated to  the engine, so they do not need to cache the data themselves. This would be very unique and
efficient solution for us because much more data fits into the memory than with a separate engine and DAC. For fast data access and
filtering we use memory datasets but reaching memory limits is something always to watch for.  EDB offers all what memory datasets
do, plus so much more. But it is all ruined by the lack of precise scrollbar handling. Grids do not cut it, so we are back at square one
with doing all the filtering with memory datasets again instead of the power of SQL, which would allow to do more than we can do now.

And I have not even mentioned the lack of "cross IDE" (Delphi, Lazarus) grids / memory datasets, which spoils the "single source for all
platforms" idea, which is the other main reason why I am so much interested in EDB.

Leslie,

<< I can understand your frustration about being forced into the same
conversation time and time again, but you could look at it as an extremely
hard to implement feature request popping up regularly, which bugs some of
your (real + potential) costumers a lot. >>

How our customers feel about the situation really doesn't matter here,
because it is a technical issue.  We either have slow update performance, or
we have an accurate scroll bar.  We had this discussion before EDB was even
released, and the decision was made to go with update performance.

Recalculating a row position on every single cursor movement in a table or
result set is a dog, and virtually unusable for most situations.  It is
quicker to load the entire set into memory and assign row positions there.

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.

--
Tim Young
Elevate Software
www.elevatesoft.com