Hi,

we are using DBISAM since a while but DBISAM doesn't support sequenced datasets.

Does the ElevateDB support sequenced datasets (we would need sequenced queries)?

That would be my biggest wish for eastern, christmas and birthdays of the next 5 years

Regards,
Robert

<<Does the ElevateDB support sequenced datasets (we would need sequenced queries)?

What is a sequenced dataset?  Do you mean supporting RecNo?

PK

Robert


Doesn't the S in ISAM in DBISAM stand for sequential?



Roy Lambert

Hi PK,

yes, I mean supporting RecNo so that the scrollbars in a DBGrid works with more than the 3 states "top", "middle" and "bottom"

Regards,
Robert

<<yes, I mean supporting RecNo so that the scrollbars in a DBGrid works with more than the 3 states "top", "middle" and "bottom"

In that case, the simplest solution is to load the query result into a TClientDataSet (or kbMemDataset or JEDI's TJvMemoryData).  The speed will of course deteriorate with the size of query
result.

PK

Robert,

<< we are using DBISAM since a while but DBISAM doesn't support sequenced
datasets. >>

Yes, it does.  Only when you have an active filter does DBISAM not support
them.

<< Does the ElevateDB support sequenced datasets (we would need sequenced
queries)? >>

No.  It involves a lot of extra overhead that reduces overall SQL
performance, etc. for the single benefit of the scrollbars and a "Record x
of x" type of display.

See this thread for more information on ElevateDB:

http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=16&msg=66&page=1#msg66

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Doesn't the S in ISAM in DBISAM stand for sequential? >>

That's a different type of sequential.

--
Tim Young
Elevate Software
www.elevatesoft.com

<<It involves a lot of extra overhead that reduces overall SQL
performance, etc. for the single benefit of the scrollbars and a "Record x
of x" type of display.>>

Couldn't agree more.  If the dataset is very large, the precise number of records is not that useful to users.  If the dataset is small, one can always
use TClientDataSet to load the entire result set without a single line of coding.

PK

The problem at using a TClientDataSet is the performance. We have about 3500 customers of our software - the one has 30 items in the database and the next one 300 000 items... And believe me - a TClientDataSet isn't really fast on 50 tables with
300000 datasets each. We already tried to use the QuantumGrid which "caches" all the data in the local memory - but thats to slow for our software.

All our data in the Grids comes from SQL-Queries with different "WHERE's" - so the scrollbar-position NEVER works in the sequenced mode. It just would be fine if any SQL-Function like "RecordNumber" would be available that counts each dataset. Then
every user could decide if he wants to see the correct scrollbar-positions or if he wants to see the better performance. And we could make a CheckBox into the programm-settings, so the end-user can decide which mode he wants to use...

That could be a really, really nice feature - and I am sure that I am not the once customer wants to see that feature...

Robert

Robert,

<<  It just would be fine if any SQL-Function like "RecordNumber" would be
available that counts each dataset. Then every user could decide if he wants
to see the correct scrollbar-positions or if he wants to see the better
performance. And we could make a CheckBox into the programm-settings, so the
end-user can decide which mode he wants to use... >>

The problem is that such functionality is all but useless except for small
datasets.  IOW, the majority of your customers would probably end up turning
it off once they realized what the performance difference was.   Dataset
positioning and refreshes occur a lot more than you realize just by looking
at things from the outside.  All of this activity ends up with a multiplier
effect on the performance drag of the "counting" process.

--
Tim Young
Elevate Software
www.elevatesoft.com