Jeffrey, I did not quite get your question.
Records in Table does not relate to QUERY in any way, because you are comparing
a sort of static number, total records in a table, to the result of a dynamic
operation.
Did you mean compare:
Set Query Destination(into variable;$nrecs)
query….
Set Query Destination(into current selection)
as opposed to
Query…
$nrecs:= records in selection ([table])
There I can see a viable comparison, and without running any real tests, gut
feeling tells me the first would be quicker. The difference is that in the
second case the first record in the selection is made available to the client,
thus transferred over the network. While i the first case, all that sent from
server to client is a number! Thus network wise, first option sounds quicker.
Now, back Records in Table, one would think that would be a known variable,
that 4D would have available at some place. Well, it does not… first time you
call Records in Table, 4D seems to actually calculate the # of recs in a table,
and on a large DB it’ll take some time to respond. Then it caches that number,
and subsequent calls are quicker. I have a form on most of my apps, where I
present a list of tables along with their record count. On a 70Gb datafile,
with 100s of table, populating that list can take a measurable amount (the
first time).
julio
> On Oct 19, 2017, at 3:28 PM, Jeffrey Kain via 4D_Tech <[email protected]>
> wrote:
>
> We've been using the new Get Database Measures command to take a look at what
> our application is actually doing, and plotting some of these metrics to our
> dashboard... for example, most frequently run queries. This particular query
> popped to the top, executing a few hundred times per minute.
>
> And all it's doing is waiting for a relatively rare condition to happen (and
> a record to appear in this table). It might happen at most once or twice per
> day, maybe only once every few days, but when it happens it has to be dealt
> with immediately. It's such a waste to be constantly querying for a record
> that 99999 times out of 100000 won't exist.
>
> I feel like I'm missing an obvious solution.
>
> --
> Jeffrey Kain
> [email protected]
>
>
--
Julio Carneiro
[email protected]
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
