Mark records in a Query without touching its table?

[G Gabriel]

Re: Mark records in a Query without touching its table?

Brett:
Here is yet a simpler approach:
When create the first query, give each a unique name.

[brett s]

Re: Mark records in a Query without touching its table?

Brett:
Here is yet a simpler approach:
When create the first query, give each a unique name.

That's a good idea worth pursuing. I recall I am limited to four at any one time, which could be somewhat restrictive. And I need to cascade them (compose one query using the output from a previous one) which I have never achieved successfully, although I understand it can be done (the A5 query genie seems to allow this as an option). I have previously found the A5 documentation lacking essential information in explaining both cascading and naming queries. But I'll give it another go.

[G Gabriel]

Re: Mark records in a Query without touching its table?

I am limited to four

That's what the help file says, but it is not so.
Nonetheless and as a precaution, use query.detach()

information in explaining both cascading and naming queries

Naming:
query.description = "query_name"

Cascading:
You could use AS or:
<OBJECT>.INDEX_SET()

You might run in trouble if a lot of users are running queries at the same time before the system has a chance to detach others.

[brett s]

Re: Mark records in a Query without touching its table?

Gabriel, thanks for the warning about over use of queries. I assumed (perhaps incorrectly?) that the query limits are per user per table and not just a global per table. After all for the latter to be the case it would require A5 code running on the server to do the counting and arbitration, which is not what occurs in practice. And of course all the query lists (the *.mpx files) are located on each users local disk, not the server, which tends to support my theory?

[G Gabriel]

Re: Mark records in a Query without touching its table?

Brett:

After all for the latter to be the case it would require A5 code running on the server to do the counting and arbitration, which is not what occurs in practice. And of course all the query lists (the *.mpx files) are located on each users local disk, not the server, which tends to support my theory?

No...I am afraid it's at the server level as alpha allocate a number of slots for queries, but as I mentioned, the limitations as defined in the help file do not hold true when tested. I wrote a thread about that a while back.

In any case, if you are talking about 3-4 users accessing the same table and generating queries at the same time, you probably be OK, depending on how complicated these queries (filter, sort) are. On the other hand, if you have a dozen users doing the same, you will definitely have a problem.