Difference between revisions of "VbzCart/queries/qryRstks active"
Jump to navigation
Jump to search
(doc: usage, new opposite query) |
(obsolete) |
||
| Line 1: | Line 1: | ||
==Details== | ==Details== | ||
| + | * '''Obsolete''': use '''cRstkReqs::SQLfor_Active_NewestFirst()''' instead | ||
* '''Returns''': List of restock requests for which we are currently expecting one or more shipments; the exact opposite of {{vbzcart/query|qryRstks_inactive}}. | * '''Returns''': List of restock requests for which we are currently expecting one or more shipments; the exact opposite of {{vbzcart/query|qryRstks_inactive}}. | ||
* '''Requires''': {{vbzcart/table|rstk_req}} | * '''Requires''': {{vbzcart/table|rstk_req}} | ||
| Line 6: | Line 7: | ||
** '''2008-11-19''' Created for new restock process | ** '''2008-11-19''' Created for new restock process | ||
** '''2008-11-20''' Including '''WhenClosed''' (new field) in the filter | ** '''2008-11-20''' Including '''WhenClosed''' (new field) in the filter | ||
| + | ** '''2015-12-31''' Replacing this with PHP-generated SQL | ||
* '''Notes''': | * '''Notes''': | ||
** We don't want to exclude requests just because a shipment has been received, because that shipment might not have included everything in the request. Once a request is marked closed (via '''WhenClosed'''), however, it means we are not expecting any further receipts from that request and we will need to request again if there's anything not yet received. | ** We don't want to exclude requests just because a shipment has been received, because that shipment might not have included everything in the request. Once a request is marked closed (via '''WhenClosed'''), however, it means we are not expecting any further receipts from that request and we will need to request again if there's anything not yet received. | ||
** At one point, doing a JOIN with rstk_rcd seemed to make the query run faster, but this may have been an illusion due to caching by MySQL and not enough testing. | ** At one point, doing a JOIN with rstk_rcd seemed to make the query run faster, but this may have been an illusion due to caching by MySQL and not enough testing. | ||
==SQL== | ==SQL== | ||
| − | + | <mysql>CREATE OR REPLACE VIEW qryRstks_active AS | |
SELECT rq.* FROM rstk_req AS rq | SELECT rq.* FROM rstk_req AS rq | ||
WHERE (rq.WhenClosed IS NULL) AND (rq.WhenKilled IS NULL) AND (rq.WhenOrphaned IS NULL);</mysql> | WHERE (rq.WhenClosed IS NULL) AND (rq.WhenKilled IS NULL) AND (rq.WhenOrphaned IS NULL);</mysql> | ||
| − | |||
Latest revision as of 18:43, 31 December 2015
Details
- Obsolete: use cRstkReqs::SQLfor_Active_NewestFirst() instead
- Returns: List of restock requests for which we are currently expecting one or more shipments; the exact opposite of
- REDIRECT Template:l/vc/query.
- Requires:
- REDIRECT Template:l/vc/table
- Used by: qryRstkItms_active, qryRstks_unsent, page for displaying expected restocks
- History:
- 2008-11-19 Created for new restock process
- 2008-11-20 Including WhenClosed (new field) in the filter
- 2015-12-31 Replacing this with PHP-generated SQL
- Notes:
- We don't want to exclude requests just because a shipment has been received, because that shipment might not have included everything in the request. Once a request is marked closed (via WhenClosed), however, it means we are not expecting any further receipts from that request and we will need to request again if there's anything not yet received.
- At one point, doing a JOIN with rstk_rcd seemed to make the query run faster, but this may have been an illusion due to caching by MySQL and not enough testing.
SQL
<mysql>CREATE OR REPLACE VIEW qryRstks_active AS
SELECT rq.* FROM rstk_req AS rq WHERE (rq.WhenClosed IS NULL) AND (rq.WhenKilled IS NULL) AND (rq.WhenOrphaned IS NULL);</mysql>