Tim,

What will recno give in the case of a query. Are queries any different to
tables in this instance, or will both operate the same?

Cheers

Adam.

<<"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

I'm very close to getting the pre-beta completed, and I'd like to get some
feedback on the use of statistics in the indexes in ElevateDB.  First, a
little background......>>

Belatedly, I'd vote for no stats. So has a decision been made on which way you are going to go?

DOM

David,

<< Belatedly, I'd vote for no stats. So has a decision been made on which
way you are going to go? >>

The stats are gone, and the stat estimation works great in its place.  The
maximum the estimation is off is about one index page worth of rows or
~200-300 avg, which is very small considering the table had 104,000 rows in
it.

--
Tim Young
Elevate Software
www.elevatesoft.com

Adam,

<< What will recno give in the case of a query. Are queries any different to
tables in this instance, or will both operate the same? >>

Both will operate the same, and both just return 0 now.  However, you can
*set* the RecNo property to tell EDB to navigate to a specific sequence
number.  It's not the fastest in the world, but it is fast enough.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:6A5B11E1-D1BC-4832-9CF2-98A5218D1EB0@news.elevatesoft.com:

> Adam,
>
><< What will recno give in the case of a query. Are queries any
>different to
> tables in this instance, or will both operate the same? >>
>
> Both will operate the same, and both just return 0 now.  

Tim,

didn't you mention that it would return the data table's RecordID, rather
than zero?

That would suit me much better, as I need to be able to align non-data-
aware controls to Query records more often than not. And non-data-aware
grids have their own sequential numbers, so I can use them to find the
(hidden) RecordID I read from the Query when loading the grid.

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.24 Build 1)

Chris,

<< didn't you mention that it would return the data table's RecordID, rather
than zero? >>

Yes, but I changed this since you can always access the RowID via the Fields
property or FieldByName() method.  Of course, I really don't care either
way, so if there's a problem with this, then I can put it back in.  The main
issue I had with it was the impedance mismatch between having the RecNo
property return the RowID, but having an assignment of the RecNo property
navigate to a sequential position in the dataset.  I thought that it might
be a bit confusing.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:44DA1F82-09D1-4AF6-B6CF-A938F0115464@news.elevatesoft.com:

> Chris,
>
><< didn't you mention that it would return the data table's RecordID,
>rather
> than zero? >>
>
> Yes, but I changed this since you can always access the RowID via the
> Fields property or FieldByName() method.  Of course, I really don't
> care either way, so if there's a problem with this, then I can put it
> back in.

No problem for me, so long as I have some way to identify every row I
read from a Query with a unique Integer. FieldByName(RowID) will do fine.

>  The main issue I had with it was the impedance mismatch between having
> the RecNo property return the RowID, but having an assignment of the
> RecNo property navigate to a sequential position in the dataset.
> I thought that it might be a bit confusing.

I agree with the "impedance mismatch".

So is there no way to navigate to a given row as one does by assigning to
RecNo in DBISAM 4? I mean without setting bookmarks? I've got to do a
sequential search in the dataset for the RowID I saved in my hidden Grid
column? (since a binary search won't work as RowID's not sequential)

I'd perhaps be better off closing the initial Query as soon as I've
filled the grid, and reopening it on a single RowID if I need to recover
extra fields or use a TwwRecordView for update when the user clicks on a
row in the grid... hmmm... (scratches head, while thinking out loud)

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.24 Build 1)

Chris,

<< So is there no way to navigate to a given row as one does by assigning to
RecNo in DBISAM 4? >>

Sure, you can either set the RecNo to a given logical number and EDB will
navigate to that logical position in the dataset, or you can make sure
there's an index on the RowID column and simply do a Locate or FindKey on it
to position on a given row.  Of course, using bookmarks is probably easier
than any of that if you want to position on a specific row, but sometimes
that may or may not be what you want.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:EED18B39-2094-40FA-B8D5-6267B543E339@news.elevatesoft.com:

> you can either set the RecNo to a given logical number and EDB
> will navigate to that logical position in the dataset

Ah, yes, that's what you said earlier, sorry.

which begs the question:

if EDB can find a record by its sequential position in the dataset AFTER
its built it up and dispatched it, why can't it just add the sequential
number (to recNo) on the fly, as it constructs the dataset, without
referring to any statistics?

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.24 Build 1)

Chris,

<< if EDB can find a record by its sequential position in the dataset AFTER
its built it up and dispatched it, why can't it just add the sequential
number (to recNo) on the fly, as it constructs the dataset, without
referring to any statistics? >>

Think bookmarks, findkeys, locates, etc. which move the record pointer
arbitrarily to a given position in the dataset.  Calculating the logical
position of the record pointer at such a juncture can be very expensive if
the record pointer is in the middle of the dataset and the dataset contains
a lot of rows.

--
Tim Young
Elevate Software
www.elevatesoft.com