Jump to content

fenway

Staff Alumni
  • Posts

    16,168
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by fenway

  1. Clearly not tested -- there's no join condition.
  2. fenway - read ^ Sorry, typo ... I think there's nothing wrong with this approach... jaymc?
  3. Always the most recent? Then you can skip the "first" one with LIMIT and an offset.
  4. If you actually use the TIMESTAMP column, then simply set to your server and client times zones appropriately, and mysql will transparently handle the rest.
  5. There was an entire thread on this issue just yesterday....
  6. And you're sure that these are actually the same record in the table? that seems impossible....
  7. Yes, but you rarely want floating-point precision -- if you're dealing with "real" numbers, use DECIMAL. Trust me.
  8. Sigh... you're got a hash collision on V_ID -- look more closely -- column aliases will help you out.
  9. Wait... so why would the difference work? EDIT: Oopsm, meant "not work"...
  10. That depends.. how evenly spread is the data?
  11. They will still work -- and probably even better. I suggested composite because you're joining on two values....
  12. If you still have issues, then echo the actual sql statement.
  13. Improvement, yes... but are those compositive indexes?
  14. Still... "*" and GROUP BY don't mix... garbage return values. Only valid column to get back here is "userid".
  15. Very little downside to an index -- performance penalty to leave off a useful index is HUGE! Try composite index on ( linktab.PROCESS_KEY, linktab.ELT_NO ) and composite index on ( process.PROD_NAME, process.JES_SEQUENCE ) Then post EXPLAIN again.
  16. If you left join and the record dont match, the "right" table will be NULL-ed out -- so you can use an "IS NULL" to find them easily.
  17. The latter is better -- and faster -- and doesn't use improper group by logic.
  18. A.K.A. SHOW CREATE TABLE. Yeah, you have no indexes.
  19. Let's see the EXPLAIN output.
  20. Sounds like a job for a LEFT JOIN.
  21. Yes, echo $parcel_sql
  22. The problem is that mysql is set-based -- so it doesn't know about the "next" or "previous" row -- your'e asking it to be psychic.
  23. Define "doesn't work" -- any all that code doesn't help.
  24. That wouldn't make ANY sense -- then there would be no way to EVER insert a blank string!!!!
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.