kgenly

And I just figured out how to mark a topic as solved, so I'm going to do that. Thanks guys!

Okay, I think there's a lot of confusion in the air here.. Fenway is telling me to select topics, and you're telling me to group by topic which I could only do if I switched tables completely and selected from the post table instead of the topic table. There's three different tables at play here. The solution I'd come up with earlier was: $result = mysql_query("SELECT t.ID, t.subject, t.date, t.byUser, t.byChar, t.locked, t.sticky FROM rp_forumtopics as t LEFT JOIN (SELECT topic, MAX(date) as maxdate FROM rp_forumposts GROUP BY topic) as r ON t.ID = r.topic WHERE t.forum='$forumID' ORDER BY t.sticky DESC, COALESCE(maxdate, t.date) DESC LIMIT $start_from, 20") or die(mysql_error()); Which is working very well for me and does everything I want, including putting sticky posts at the top and then ordering by most recent posts beneath that, and I can read it and understand it well enough to modify it because, well, I wrote it. So again, if there is a more efficient way to do this or one of you is spotting a glaring error that will jump out and bite me sometime in the future, I'm all ears. On the other hand if we're currently engaged in guessing how to make it work or teaching me to build a query I understand, thank you sincerely for your concern and your time but we can probably mark this one as solved.

Nope. The most recent for only one given forum at a time. Sorry for the confusion.

I only want results of one forum at a time. Wouldn't a WHERE be more accurate?

Thanks, great read! For your suggestion, what am I supposed to be grouping the topics by?

I think I may have solved this, I am now using: SELECT t.ID, t.subject, t.date, t.byUser, t.byChar, t.locked, t.sticky FROM rp_forumtopics as t LEFT JOIN (SELECT topic, MAX(date) as maxdate FROM rp_forumposts GROUP BY topic) as r ON t.ID = r.topic WHERE t.forum='$forumID' ORDER BY COALESCE(maxdate, t.date) DESC LIMIT $start_from, 20 This may be horribly inefficient, but it's a step in the right direction as it does what I want. I'm open to better ways of implementing this if anyone knows one, though!

mysql_fetch_array() only gets one result row at a time. If you are expecting lots of results to come back, you need to use a loop to handle each one at a time. For example: while ($row = mysql_fetch_array($result)) { echo $row[0]; }

I think the mySQL you are looking for is something like... SELECT * FROM promo JOIN item ON promo.id = item.promo_id WHERE promo.id='$promo_id' The important part is ON promo.id = item.promo_id. This tells mysql to take your item table and merge the items together with their promotions, but only where the promo_id field matches an id of a promotion on the promo table.

I'm certain that this is a very common problem, but a great deal of googling has so far only provided me with a partial solution. I have a forum that is broken up into three tables: forums, topics, and replies. I am trying to list the topics in a given forum, based on when the most recent reply occurred to that topic. Or, if there are no replies, then the time that the original topic was created. So far I have this: "SELECT t.ID, t.subject, t.date, t.byUser, t.byChar, t.locked, t.sticky FROM rp_forumtopics as t LEFT JOIN rp_forumposts as r ON t.ID = r.topic AND r.date = (SELECT MAX(date) FROM rp_forumposts WHERE t.ID = r.topic) WHERE t.forum='$forumID' ORDER BY COALESCE(r.date, t.date) DESC LIMIT $start_from, 20" The problem is that the MAX(date) seems to select only the most recent post made in the entire forum, not the most recent for every topic. Can anyone help? Thank you very much in advance.

Sorry, I think I was confused about the question. There is one physical server that I share with others, but each user has their own 'virtual' machine within that, so it's just me using the tmp file in question.

Yes, and yes. I just found some information saying session_cache_expire() has nothing to do with the life of the session and is just something sent in the headers about how long it's safe for browsers to cache something. How confusing! It still doesn't really explain to me why my sessions were expiring faster when I was making random changes to one of the variables. I'm testing ini_set("session.gc_maxlifetime", "18000"); before my session_start() right now, as that was suggested to me elsewhere.

I'm not sure if this is the correct part of the forum for this question, but it was my best guess! I run a website that allows users to create profiles for characters they have thought up and like to play with. It's sort of like myspace for roleplayers. My users have been complaining that they are being logged out of my site even when they are using it actively. I ran some tests to see what the problem might be, and eventually discovered that sessions are expiring unexpectedly. The default for my host appears to be that sessions are meant to expire after 180 minutes (3 hours) of inactivity, so I ran a test where I logged into my site, then set a timer and let my browser sit idle for two hours. I then used my site again, making edits to profiles and whatnot, which I expected to reset my session's life for another three hours. However, when my timer went off after two hours and I tried again, I discovered my session had expired and I was logged out of my site. As far as I can tell, logging in sets the session to expire in three hours, regardless of whether the user is still actively using the site or not. (There is a PHP session_start() call at the top of each of my pages). After doing a lot of searching, I had the theory that the garbage collector was checking not the last time of access, but the last time of modification, so I added to the top of every page something that changed a variable in the session every time a page was loaded. When I ran the test again, I was unable to make it to the first two hour mark, let alone the second. I ran this test twice more and had the same issue. Why would editing the session result in it being shortened?? I've also tried putting a session_cache_expire() call before each session_start() that was set to extend the cache expiration out to about a week, but it didn't seem to have changed anything. I don't understand this behavior at all. I asked my host why my sessions were expiring early and never being extended through use or modification, but all they said was that it was expected PHP behavior and I should ask someone to help me with PHP. Granted, I'm a fairly green programmer, but this isn't the behavior I expected, and not the behavior that seems to be described in the manual, unless I am reading it completely wrong. Does anyone have any thoughts? This issue has resulted in my receiving lots of ugly hate mail from people who had their work eaten when they tried to submit something only to discover they'd been logged out while they were typing their monster posts, and is souring the atmosphere in a community that is otherwise really enthusiastic. Any help would be greatly appreciated!