Jose Eduardo Helminsky wrote:

>
> Ok, I understand your point. The main concerns about database engine always
> is related with performance, integrity and the last (user interface).
>


In this order:

#1 is Integrity - It doesn't matter how fast your database is if the
data is corrupt. I'm willing to give up a few uSecs for the data being
intact when I need it.

#2 is Speed - If the data is good, give it to me as fast as possible,
but not at the expense of #1

#3 is Features - Give me a whole bunch of goodies to make my life easier
when integrating your database into my application, but don't do so at
the expense of #1 and #2.

Mark

Mark

Fantastic explanations.

I completelly agree with you. What I was trying to say is exactly what you
wrote.

Eduardo

And what's wrong with the shh you know who way:

#1 is Integrity - of your bank account so you can afford to buy the stuff

#2 is speed, lets build in delay loops that we can take out later and say we've improved the thing

#3 is features - the more the better, who cares if 99.99% of all users won't ever use them, it looks better on th package


Roy Lambert

> If I use a TedbQuery instead of a TedbTable to populate a grid which of
> the following are true:
>
> 1) With Statistics = accurate scrollbars
> 2) Without Statistics = 3 state
>
> Just want to be clear on this.

I would be curious about this too since most of my work is done through
queries.  Also, since I use the devEx Grids, I have no need for the counts
to be perfect.

Bill

AJ,

<< Ok I don't pa much attention to the scroll bars so enlighten me if you
will.

If I use a TedbQuery instead of a TedbTable to populate a grid which of the
following are true:

1) With Statistics = accurate scrollbars
2) Without Statistics = 3 state

Just want to be clear on this. >>

Both are true, under the conditions that the query is not a live query and
there are no filter conditions (WHERE clause).  If that is the case (live
query with filter condition), then 1) is False.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< Well, please decide and release it. This discussion seems to take
forever. >>

Sorry, just trying to cover all of the bases.

--
Tim Young
Elevate Software
www.elevatesoft.com

Ralf,

<< Of course, and I will buy ElevateDB anyway >>

That always makes me feel better.

--
Tim Young
Elevate Software
www.elevatesoft.com

Chuck,

<< I may be over-simplifying the issue, but if transactions can overcome
(most of?) the performance problems of extensive updates with statistics,
and the only other significant problem is large indexes (in an age of 200GB
hard drives for 50 bucks) then keep statistics and ...

  - Those of us with big tables need to master transactions >>

No, you are certainly correct.  However, there are some future "would be
really cool" items that also affect the decision.

--
Tim Young
Elevate Software
www.elevatesoft.com

Stefano,

<< So, we have to forget 'record 1 of  10'  with direct access to ElevateDB
tables, true? >>

Well, not yet.  But that is the topic being discussed, yes.

<<  (because using Ado in .net application we still have it natively in its
layer; So even with Clientdatasets); >>

Correct.

<< But if I can substitute this, for ex.: >>

Actually, as someone already pointed out - you can use bookmarks for just
such a purpose.

<< My need on old recno is only for show "Record x of xx" to the user, but I
can change this;  If  you give me the logical value of record (for ex: 390),
and I can move to it assigning a table property, I have only to replace the
old recno with new property. Naturally if you promise us that the new index
system boost performances (I have all kind of tables; from 3 records to 5
millions of  records). >>

Removing the statistics will reduce the amount of index I/O, which naturally
reduces the time it takes to perform any given index operation, be it
reading, writing, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< It's faster using RecNo. >>

It's the same, actually.  Setting the RecNo does the equivalent of an index
search but, instead of comparing index keys, DBISAM compares the logical
position via the index stats.

--
Tim Young
Elevate Software
www.elevatesoft.com