D3

There is the (T option which does a count and percentage while it
selects a table (or count or ..). It displays, what the docs call,
'approximate' count of rows in the table.

Is there a way to get the static count from the table. I have
searched here and in the documentation and not found it.

Thanks

The "approximate" count comes from the file-of-files... it is
approximate only because, in a dynamic environment, items may be in
the process of being written to, or deleted from, the file in
question while you are counting it. (Also, since it is based on the
fof, you have to have run a recent file-save with the (s option, or
counted or selected the file before the fof count is updated.

There is an estimate-count verb that gives you this total instantly. I
usually create a synonym called ecount because it's easier to type.

ecount (or estimate-count) uses a user exit, so I also have a
subroutine to do the same thing:

01 sub ecount.sub(filename,count)
02 * returns estimate-count of number of items in filename
03 * 03-13-00 asb
04
05 count = 0
06 open filename to fv else return
07 read x from fv,"" else null
08 count = oconv("","u0065") ;* returns -1 if estimate not available
09
10 if count gt 0 then
11 print count:" items in ":filename:"."
12 end
13
14 return


/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

On Mar 6, 10:50 am, "Scott Ballinger" <scott.ballin... (AT) gmail (DOT) com>
wrote:
Thanks Scott ..

So this is just based on the last file-save .. humm

Don't mean to imply that, and I don't think so. I am guessing that
here has to be a fof entry for the file, thus if no file-save, no fof
entry. However, I think the select and count verbs will create an
entry in fof (and populate it with the current count) if it's not
already there. Look at the source for estimate-count... if the user-
exit returns -1 then then it executes a regular "count" and from then
on it (the estimage-count verb) knows the current count (which is also
updated when items are created or deleted via the editor, delete,
copy, basic, whatever; like the btree indexes are updated no matter
how a file is changed).

Maybe I am wrong about the fof... and the current count is just kept
in the fcb somewhere? Anyway, estimate-count is not dependent on the
filesave, or the last count or select (those are just required to
initialize it). It is updated in real time and in my experience highly
reliable.

/Scott

On Mar 6, 11:55 am, "Scott Ballinger" <scott.ballin... (AT) gmail (DOT) com>
wrote:
thanks for the follow-up. sorry for the misunderstanding. will give
it a try

On Mar 6, 1:48 pm, "dtsig" <d... (AT) hotmail (DOT) com> wrote:
The count is stored in the FCB and updated real time and fairly
reliable: The reason it's accuracy must be qualified as only being
"approximate" -- is that the update is not done under lock and can on
rare (?) exception miss updates (causing the count to be over/under.)

On Mar 8, 2:21 am, "dzigray" <goo... (AT) bridge2 (DOT) com> wrote:
Really?! You mean there is core code that increments a count without
taking a lock? And we're talking about the FCB? Wouldn't updates to
the FCB have to be ACID? Also, I don't have a D3 system available atm
but I was pretty sure the count was in the FOF. Have I therefore made
an incorrect assumption that this is where the estimate-count comes
from when it really comes from the FCB?

As long as it's stated that the counter may be inaccurate, and is not used
for any critical reason, no reason to do it under lock. Though, of course,
at the machine level, the lock's plenty fast.

Chandru
"Mike Preece" <michael (AT) preece (DOT) net> wrote

On Mar 8, 4:39 am, "Mike Preece" <mich... (AT) preece (DOT) net> wrote:
Personally, I would have implemented this "under a resource lock" (in
part to ensure its own structural integrity -- ie. the integrity of
the DWORD counter). Nonetheless, the near-approximate counter-value
still has use in current form (i admit having regular occassions for a
very-close "estimate".)

Chasing the ACID discussion, however, one should consider that in any
situation where an "exact count" is required, the application can
implement/manage such a resource on its own -- especially considering
that IF an application REALLY has to make a decision/action
surrounding the exact item count-value... it must do so under some
semaphore/transaction-integrity to know that any subsequent-action
being performed is valid through such transaction -- all of which...
then makes the original issue of it being performed "under-lock" as
"moot". To be used as part of any transactional-integrity, certainly
at the system-level one would not implement EVERY application-level
semaphore (eg. LOCK, READU...) as to block all system-updates to ALL
item-counters; which necessarily requires application-level CONTROL of
the resource to be useful for an "exact"-count resource.