Stephen Russell wrote:
> What I see in that GUI is not the order(s) but the Queue table.
> Right?  Or is that a join to Orders that show B.Braun as the customer
> as well as the equipment table for the process as well?.


No, that's NOT the queue...that's the Orders to be nailed.  They get
sent to the queue AFTER they're nailed.


>
> Does your Queue table have a status column?  Used to represent what
> station the material is at?  Or will you have to portion out 560
> ordered, 280 nailed and 280 treated?

There's no status column (nor do I want that).  You've got the ordered
qty (e.g., 1000), and then they send off portions of that qty to the
queue as they're nailed.  So you'll have perhaps 3 bundles of
300,400,300 sent to the treatment area.  The status would be either in
nailing, some sent to queue, and then all qty sent to queue.  What's
important is not the status but just the OrderedQty vs. TreatedQty.  And
some orders don't get treatment, btw.


> I see that you only need to do the query one time and include more
> group by data to give the granularity you need.

No, because that schedule "magnet board" is shown on a big screen in the
production office as well as running on a few different workstations
(for VPs who want to see the active work on the floor and what's in the
treatment queues), the database is requeried quite often perhaps.  It's
not just a once and done query...that would have been nice and easy and
thus I would have just relied on the SUM() LEFT JOIN query.  Because
it's hit "often" I employed the QTY_IN_QUEUE table with a simple INNER
JOIN.  Or perhaps a simple query for the given iOrderID...can't recall
exactly...would have to look back at the code.  But I do know that after
I employed this design and a few other optimizations, it was lightning
quick as opposed to before where it was too slow to be useful.  Recall
this is a web database that's being polled from a VFP9 rich client app.


>
> Depending on how much material volume you have, do you need to update
> every min. or every 3?  This query should only take a second or two to
> run,  it should be all in ram if your running this frequently.


It's not in RAM because it's a MySQL database on the web.  If it were
Foxpro data, yes, you'd be right that it'd be in RAM.  I think they've
got their updates/requeries set to run every 1-3 minutes, depending on
the user's preference set as his workstation.





_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED]
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to