Jump to content

fenway

Staff Alumni
  • Posts

    16,168
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by fenway

  1. Well, i never see $flags being assigned.
  2. Well, the first line should definitely have "hidden" in quotes... but sometimes it's coming back as blank.
  3. Whic htime?
  4. Don't make us count... which line is that?
  5. That if() line has syntax errors.
  6. Not really sure what you want... an UPDATE statement? Assuming you have the expiry_date field, you can use " + INTERVAL x DAY" to push it push.
  7. DATE_FORMAT( yourDateTimeField, '%d-%m-%Y )
  8. Hmm... you could issue a "SELECT NOW()" periodically with a background process...
  9. Unfortunately, the list changes... but yes, I guess I could right a macro that compensated for that.
  10. I'm not familiar with mysql_pconnect() -- a PHP function -- so you'd have to see what everyone else says.
  11. You mean persistent?
  12. Really? No one? The one time I need help ;-( LOL
  13. Could you post a link to a valid HTML page with this JS script running?
  14. Welcome to PHPFreaks! TEXT/LONGTEXT is quite undesirable -- and in v5.0+, VARCHAR can be 65K, so you rarely need TEXT (VARCHAR was only <=255 in v4.1 and below). These very large fields have implications for sorting/group by operations, data seeks, etc. They should be avoided if possible -- and if not, they should be in their own table, ideally. BIGINT it *really* big... INT gives you 4 billion numbers (8 billion if it's UNSIGNED)... takes up half the space, which can be very important for indexing too! You can use TIMESTAMP for created/modified, but it's a bit tricky, there are time zone issues, max date = 2037, etc., etc., so be warned. I prefer DATETIME, even though it's a few extra bytes. So, in a nutshell, drop the BIGINTs, use VARCHARs with reasonable lengths (be generous, but not an order of magnitude), stay away from keywords like "date", and don't use [LONG]TEXT fields. Obviously, indexing some other fields will be necessary, too.
  15. The table alias isn't part of the column name that comes back... it's still just "id". Which will cause a collision with "cat.id" -- so use column aliases (e.g. cat.id AS catID) and you'll be fine.
  16. Then you need to UNION these two tables, and then count on the "merged" result.
  17. Seriously? var q = eval("document.pooh."+element+".value.length"); eval() is evil. var q = document.pooh[element].value.length; And since it's in a form, you should be able to navigate the hierarchy from the form object, no need to go back to document, just takes longer.
  18. Not entirely true.
  19. That looks hungarian. What's the relationship between the two tables?
  20. Move the mysql_error() line to the _query() line in a die() statement.
  21. fenway

    Left join help

    Let's see some sample data, table structure, and all the queries involved.
  22. *smack* No! Don't feed the animals! Yes, I'm curious too... granted, they don't have an 800 number, but they've been more than helpful. I have literally hundreds of domains registered with them.
  23. 106wpm.
  24. I would prefix the fields with their respective table [alias] names.
  25. fenway

    Left join help

    1. It does that. 2. Just add a count().
×
×
  • 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.