btherl

I would try changing the session save path. It's worth a try. I wouldn't worry about the E_ALL warnings. Code that's quite solid can produce a lot of "notices", which will show up with E_ALL, and getting rid of them can often make the code less readable.

Is this server run by you or by someone else? If someone else runs it they may have reconfigured how php runs. Or even upgraded from php 4 to php 5. If the server is yours, it may have been affected by a change to the webserver, even if you didn't modify php itself. The short answer is that $_SERVER variables are not really guaranteed by php to hold any specific value. PHP relies on the web server to pass those values through, which is why they are called $_SERVER variables .. If the web server gives php different values, then that's what your script will get. The manual says this:

The session handler can be replaced by another back end, such as one that stores the data in a database. http://sg2.php.net/manual/en/session.customhandler.php Apart from that, the core session handler might hang if it can't create or read the session file, I would imagine. We had similar issues before, but it was with a custom session handler holding a lock on session data, preventing any other requests from the same session from running.

Can you get the script name from one of the other server variables? If it's in the url then you should be able to extract it from there.

Is it possible that the users table is empty? If it is you should see something like this: db=> select * from foo; -- (0 rows) You can also try selects that don't involve any tables, like this: db=> select now(); now ------------------------------- 2009-06-25 11:45:49.429334+10 (1 row) If the table is empty, you need to insert some data into it.

Browsers typically send an accept-language and accept-charset header. I don't know how much you can trust those for availability of certain utf-8 characters though, as a browser can easily "support" utf-8 without being able to display every code point. You can probably rely on accept-language more for that, as someone who accepts zh-cn ought to be able to display chinese, for example.

the_oliver, the issue here is that he wants a unique id for a VIEW, not for a table. A sequence won't work as a view is generated dynamically, so the sequence numbers would be different every time the view was queried.

"Elegant" and "run faster" are two different goals For something like this I would go for extendability and reusability before anything else, as you're likely to modify it in the future. And if rivers are only generated infrequently, there's probably not a need to make it run faster, unless it's running very slowly already.

Yep that's what I meant. I think you can improve readability with a few small functions, especially a distance() function. Then it'll read more like pseudo-code.

What you've done there makes sense to me. You could calculate the minimum distance on the fly instead of by sorting afterwards if you wanted to.

Well he said this: I'm assuming that means the ids need to stay the same when he runs the query again. Maybe it doesn't, I don't know exactly how he's using them. It might be that even random ids are good enough, as long as he doesn't reference them again later (ie they are purely to satisfy the framework, and aren't actually used by the framework). I'm thinking now that concatenating might be the best solution. Then you don't need to worry about matching ids to rows, as the rows themselves give the id.

Were you checking the wrong column?

Rivan, if you do that then you won't get the same sequence numbers each time. That means it's not a unique identifier for a result row.

Can you try setting the path argument ("/") when you unset the cookie?

The query looks fine to me. So I suspect there's no matching rows in the database. In the database, do you have "NEW" capitalized?

It's a good idea to put your query in a variable, print the variable and then run your query. That way you can see exactly what it is you are running. $query='SELECT * FROM member_messages WHERE status = "NEW" and user_id ="' . $userid . '"'; print "About to run $query\n"; $sql = mysql_query($query);

Try putting your code in a variable, printing the variable and THEN calling eval on it. That way you can see what code you are trying to run. Eg $str = "print 'hello';"; print "Executing $str\n"; eval($str);

I've never experienced this, and i use Chrome a lot with sessions. Can you come up with a simple script that demonstrates the problem?

Try this: <?php foo(); function foo() { var_dump(debug_backtrace()); } ?>

foreach ($array as $key => $value) { print "<a href='$key'>$value</a>"; }

You are fetching from the $query instead of the $result. Don't worry, I've done that a million times

Ah, no worries. Here's how: $sql = "SELECT artist_name FROM artists WHERE artist_name='$artist_name'"; echo "We're about to run this query: $sql <br>"; $result = pg_query($pgsqldb, $sql) or die("Query: $sql\nFailed with: " . pg_last_error()); while ($row = pg_fetch_assoc($result)) { echo "{$row['artist_name']}<br>"; } Then in your output you will see "We're about to run this query: SELECT artist_name ..." You can take a look there and check that the query is what it should be. If you're not sure if the query is correct or not, post the output here.

Did you echo the query?

Try this: $sql = "SELECT artist_name FROM artists WHERE artist_name='$artist_name'"; $result = pg_query($pgsqldb, $sql) or die("Query: $sql\nFailed with: " . pg_last_error()); while ($row = pg_fetch_assoc($result)) { echo "{$row['artist_name']}<br>"; } If you still get no results from your query, echo the query so you can see what's actually being called. Good luck

You can never control what the browser does. But php has a directive that will refuse any file larger than a particular size. You can read about it here: http://www.php.net/manual/en/features.file-upload.post-method.php If you use that, the upload will be rejected before your script deals with it. There is an advisory method you can use to request the browser doesn't upload anything larger than a certain size, which is also mentioned on that page. But you can't control if that is followed or not.