Charalabos Michael wrote:

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

My last company had a table with over 3 million rows.

-- AJ Marknette

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.


-AJ Marknette

Hello AJ,

> My last company had a table with over 3 million rows.

Oh boy ... That's a lot of data!

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

Hello Tim,

> I understand, but we're not throwing away functionality in DBISAM -
> ElevateDB hasn't been released yet and is a new product with different
> functionality.  There's a lot more than this that is different from DBISAM,
> so if the scroll bars are an issue then you might have a lot more issues
> that are bigger than that.  IOW, you might find that sticking with DBISAM
> for your existing projects is the best route to go, and then seeing if
> anything new coming up might be able to use ElevateDB.  Finally, there is
> more at stake here than just a small amount of speed gain.  There are
> avenues that we could take ElevateDB without the stats, that we cannot take
> ElevateDB with the stats, especially in terms of better transaction models.
> There is more than just the immediate future for us to consider.

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

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

Tim,

Tim Young [Elevate Software] wrote:
....
> There are avenues that we could take ElevateDB
> without the stats, that we cannot take ElevateDB with the stats,
> especially in terms of better transaction models. There is more than
> just the immediate future for us to consider.

Of course, and I will buy ElevateDB anyway

Ralf

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:B7C240FC-07AB-4256-8F69-57BE81F11F19@news.elevatesoft.com:

> Michael,
>
> << My friend here asks a reasonble question, regarding 2) - if you
> remove stats from index, how will you ever determine, that the index
> should be used in query optimization, or will you use any index, which
> contains selected field? >>
>
> That's what we do now (use any index that contains the field being
> filtered on as the first field in the index).  However, with the stats
> we also can determine exactly (and very quickly) what the cost of an
> index scan would be for the given filter criteria, thus enabling us to
> determine when we should punt and do a record scan instead of an index
> scan because the record scan is more efficient.
>
> << The other solution is as it is done in Mimer, where the engine
> temporarily delays statistics accumilation (so it becomes outdated)
> and then you
> may force it to rebuild stats at once. This however will not help with
> 1).
> >>
>
> Yes, and that's the big sticking point.  I doubt if most people even
> care about the stats in terms of query optimization, provided that any
> alternative is not anything more than slightly slower or faster.  It's
> the logical record numbers that are mostly at issue.
>
> << In other words the best of both worlds I think can be achieved by:
>  1. Keeping statistics in index
>  2. Delaying update of staistics in case of large insert block (this
>  can be
> done by user explicitly). In this case user will not be able to use
> sequential access until stats are updated
>  3. Force rebuilding stats manually at the end of operation. >>
>
> That's effectively what transactions do right now with the statistics.
>  The I/O factor is not an issue when caching the updates in a
> transaction. Rather, the issue occurs cumulatively during lots of
> single-row updates to very large tables that do not occur under the
> umbrella of a transaction.
>

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

Chuck Hall

--
Remove the _HATES_SPAM to reply

Ok, Tim.
So, we have to forget 'record 1 of  10'  with direct access to ElevateDB
tables, true?
(because using Ado in .net application we still have it natively in its
layer; So even with Clientdatasets);
But if I can substitute this, for ex.:
Table1.first;
while not Table1.eof do
  begin
 tmprecno:=Table1.recno;
 ......other operations that move cursor on the table;
 Table1.recno:=tmprecno; // cursor return on previous record;
 Table1.next;
 end;

with a :

Table1.first;
while not Table1.eof do
  begin
 tmprecno:=Table1.logicalrecordcount; // or your property name;
 ......other operations that move cursor on the table;
 Table1.logicalrecordcount:=tmprecno; // cursor return on previous record;
 Table1.next;
 end;

......my needs are satisfied;

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

It's true all this ?

Stefano Monterisi





"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> ha scritto nel
messaggio 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".
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Stefano,

the same you get by using bookmarks and therefore you don't need recno
property:

var bmTable: TBookmark;
::::
Table1.first;
while not Table1.eof do begin
 bmTable := Table1.getBookmark;
......other operations that move cursor on the table;
Table1.gotoBookmark(tmBookmark); // cursor return on previous record;
Table1.freeBookmark(tmBookmar);
Table1.next;
end;

Iztok Lajovic

Hello Iztok,

> var bmTable: TBookmark;
> ::::
> Table1.first;
> while not Table1.eof do begin
>   bmTable := Table1.getBookmark;
>  ......other operations that move cursor on the table;
>  Table1.gotoBookmark(tmBookmark); // cursor return on previous record;
>  Table1.freeBookmark(tmBookmar);
>  Table1.next;
> end;

It's faster using RecNo.

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

Hello Tim,
  How about creating an internal on-fly index for RecNo ? (as optional)
  (in query this can be done using "RunSum")

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