Stefano,

>......and a property at database level (or better table level) like INDEXSTAT
>= TRUE/FALSE  than can be set by programmers on project's needs?
>You have to manage 2 different logic with a great job, but we could be
>happier....
>(I don't known what can be your effort, honestly)

See Tim's reply:

>Unfortunately it's a no-go since making two different and
>incompatible table formats would be a killer for acceptance out of the gate.

Manfreft Kavetu

Hello,


> << Why not instead of removing code, comment it and then test ElevateDB
> without Statistics to see if we really want them or not ? >>
>
> Well, since I just told you what the only negative effect would be (no more
> sequence numbers), I initially thought that would be enough to elicit a
> response one way or the other.
>
> Also, the point is not how to handle changing the code (we have backups of
> everything anyways), but rather whether it is something that I can pursue
> without pissing off too many customers.

Well, it's very annoying to have a 3 step scrollbar.
So i vote no! Isn't any other way to have an accurate
scrollbar/recno without using statistics ?

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

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:E0068B77-0361-4132-B84C-F4CAB316FE8A@news.elevatesoft.com:

> 1) Accurate row sequence numbers, regardless of the active index and
> even with ranges set (but not filters).  

IIUC: row sequence number = recno?

Does removing stats actually REMOVE recno, or just make them non-
sequential?

I use the recno to find a query's record for updating from a non-data-
aware grid as the basis of my current application which I'm hoping to
distribute fairly widely, so "accurate" row sequence numbers aren't a
problem, but "no" row sequence numbers would certainly be!

As has already been said, though, users prefer a proportional scrollbar,
and removing stats removes that.

I don't personally envisage ever having more than a few hundred thousand
rows in my users' tables, so I'd prefer to keep the stats, but I have
noticed several posts in these newsgroups talking about multi-million
record tables.

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

Hi Tim

In my case it does not matter either way (sorry) .. and I
am not even sure an upgrade will be good for my little apps.

However, just to clarify it in my mind, in a properly
designed C/S implementation, will the differing I/O and
index maintenance be confined to the server so that LAN
traffic and Client I/O will be much the same?

Malcolm

--

Tim,

I vote for removing the statistics and using option #2.

--
Regards,
Jan Ferguson


Tim Young [Elevate Software] 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......
>
> Currently, ElevateDB uses statistics in indexes like DBISAM does, and
> these facilities allow for this functionality in ElevateDB:
>
> 1) Accurate row sequence numbers, regardless of the active index and
> even with ranges set (but not filters).  This also means an accurate
> grid scrollbar when there are a) no filters or ranges or b) just
> ranges set on the table cursor.
>
> 2) Exact I/O cost calculations for optimized index scans in queries
> and filters.  This means that ElevateDB can very accurately determine
> if it is more efficient to use a row scan or an index scan for a
> particular filtering operation, be it for JOINs or a WHERE clause.

Tim

If the only negative effect is "no more precision on grids scrollbar", then
is there another way to fix this ? If so, then inherit DBGrid and write a
ElevateDBGrid with precision scrollbars and you have solved the problem.

Remeber, users like grid scrollbars working as expected instead of a three
position only.

Eduardo

Eduardo,

<<Remember, users like grid scrollbars working as expected instead of a
three position only.>>

I agree. We use DBISAM to produce consumer software which gets licensed
to software publishers. So we're more interested in the "pretty" aspects than
in handling multi-million row tables in the optimal way.

Regards,
Dan

Lexicon Software Ltd, Bath, UK

Oppsss...
you have reason, sorry....

Stefano

Jerry,

<< With a new version and a lot of new code, I'd say to just keep with the
existing scheme; you're intimately familiar with how it works and there's
always ability to add an option for a different indexing scheme later.

Keep the project on track with the compatible behavior; there's always
enough extra surprises >>

The modifications are very minor, but the ramifications for doing the
changes/not doing the changes will be with ElevateDB for its lifetime, so
the decision has to be made now, unfortunately.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< NO STATS - smaller table sizes, faster writes, "inaccurate row sequence
numbers", possibly slightly slower queries due to inability to estimate
accurately

STATS - larger table sizes, slower writes, "accurate row sequence numbers",
possibly slightly faster queries due to ability to estimate accurately >>

Spot on.

<< I don't use the row sequence numbers (I also don't understand what they
have to do with statistics) >>

The row sequence numbers are simply the logical record numbers shown when
you call RecNo.  The statistics in the indexes allow us to calculate a given
logical record number for any given record very quickly, as opposed to
having to count the records up to the current record to determine its
logical position.

<< Query speed, reading your post, shouldn't be impacted much (row scan or
an index scan) and guessing it'll only be on "weird" cases >>

Basically, the estimating vs. the exact will simply skew towards more
inaccurate proportionally as the number of rows increases in the tables.
For example, very small tables (one thousand rows or smaller) will still
have very accurate estimations because there will only be a few levels (or
one) in the indexes that need to be looked at to determine the estimate.  As
the indexes "fan out", the estimates become proportionally less accurate.
However, the accuracy requirements are also lessened as the number of rows
grows.  IOW, a very large table that has an estimation that is off by a few
hundred rows when hundreds of thousands of rows are being read is still
pretty acccurate compared to a small table that has an estimation that is
only off by a few rows.

--
Tim Young
Elevate Software
www.elevatesoft.com