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

That could be done, but it would be a support headache that I'd rather
avoid.  With ElevateDB, we've removed a lot of confusing options that were
present in DBISAM such as the index compression selections, etc. and made
them automatic.  I'd hate to head down that road again and introduce another
major "option" that would entail a lot of questions along the lines of "what
is the difference between this and that".

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

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

Sure, by counting records.  However, that gets a bit slow when you've
navigated via a FindKey(), etc. to the middle of a 800,000 row table and
need to know what the logical position of the record is according to the
current index.

--
Tim Young
Elevate Software
www.elevatesoft.com

Chris,

<< IIUC: row sequence number = recno? >>

Correct.

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

The RecNo proeprty would revert to returning the row ID, which would be
non-sequential in most cases except for the primary key ordering.

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

Actually, in your case the use of the row ID would be more accurate since
with the logical record numbers the RecNo property can change whenever a
record is added, updated, or deleted.  Row IDs are invariant.

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

Yeah, we have quite a few customers that have a *lot* of data in DBISAM, and
it would be nice to give them some improvements in ElevateDB in terms of
performance.

--
Tim Young
Elevate Software
www.elevatesoft.com

Malcolm,

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

Correct.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:55C48592-368E-4612-AEE8-2F4AADF5FB85@news.elevatesoft.com...
> 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....>>
>
> That could be done, but it would be a support headache that I'd rather
> avoid.  With ElevateDB, we've removed a lot of confusing options that were
> present in DBISAM such as the index compression selections, etc. and made
> them automatic.  I'd hate to head down that road again and introduce
> another major "option" that would entail a lot of questions along the
> lines of "what is the difference between this and that".

I'm all for fewer options with more smarts built into the engine. I never
really knew what I was getting out of my index compression settings anyway.
And after a few hours of playing with the remote compression level, I found
the default was the best option.

I would trust YOUR judgment on the index statistics issue. My primary
requirements are fast searching and reading - write speed is not an issue.
My tables are always less than 100,000 records.

-Johnnie

Eduardo,

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

Well, it's certainly possible to write a grid that could do what you want.
However, I doubt if I would be the one to do it since that's kind of outside
of our scope of interest.

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

I understand, but the UI is not necessarily the prime factor in deciding
what is best for a database engine/server.

--
Tim Young
Elevate Software
www.elevatesoft.com

Remove the statistics, I don't use data-aware UI controls anyway, they
are problematic. Using C/S exclusively, I run my queries, fill my UI
controls, and close the query.

Go in
Get what you need
Get out

Hello Tim,

> I understand, but the UI is not necessarily the prime factor in deciding
> what is best for a database engine/server.

Only if they don't use UI. Most database applications do.

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

Hello Tim,

> Sure, by counting records.  However, that gets a bit slow when you've
> navigated via a FindKey(), etc. to the middle of a 800,000 row table and
> need to know what the logical position of the record is according to the
> current index.

Well, i don't have any client with 800k records. Most of my clients
are ranging to 1k (highest)

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

> Would you consider the removal of the index statistics, and the subsequent
> removal of the ability for ElevateDB to provide option 1) above
> significantly negative ?
IMO, Yes.

I think it would be best if it is made as an option for a particular
index if someone needs to update a huge table in the described manner.
This way my suggestion is: do not remove the statistics at first.
Create a separate implementation of different type of index, which
doesn't use stats. This can be done later as an additional feature.
This will result in larger footprint, but I think it'd be the best
choice if existing design allows having two different types of indexes.

My 2c anyway.

Regards,
Michael