requinix

SELECT every season where its from_date is on or before your end date and its to_date is on or after your start date. I can explain why that works if you want. So SELECT * FROM table WHERE from_date = '2016-02-27' ORDER BY from_dateIf you try that query in your head you'll see it returns the first two rows. You can also use some date functions in the query to immediately tell you how much overlap there is using DATEDIFF. DATEDIFF(LEAST('2016-03-10', to_date), GREATEST(from_date, '2016-02-27')) + 1(+1 assuming you count the end date as part of the stay; Jan 1 to Jan 2 would be two days, not one) [edit] While I'm here, how about getting rid of the "year" column? You already have that information with the two dates.

Likely not illegal per se but you may be breaking your contract/ToS with the provider, which could lead to all sorts of problems.

Always save functions like htmlspecialchars() until the very end, just before you're about to embed the text in HTML (be that with output or when pre-rendering HTML).

Does it work if you try '<3' => 'heart.gif'

echo json_encode(array('So I should not rely on json_encode() to behave the way it does? Please create a bug report so the PHP developers can remove this unsafe function.

I must have missed it because I didn't see anything in that link explaining why JSON encoders, such as json_encode(), are unsafe.

What's the HTML? Particularly to do with the textareas.

That'd be because it does not exist. There is no function "html" on DOM elements.

Please look for another tutorial. That one is teaching you bad practices that can be difficult to unlearn. if (isset($_POST['update'])){That is trying to detect that the form was submitted (and is trying to update data) but it's not looking for the right information. See how there's nothing in the form with the name "update"? However there is the submit button, with the name "submit" and the value "update". You can check for that instead: if (isset($_POST['submit']) && $_POST['submit'] == 'update'){

You shouldn't specify the hashing algorithm. password_hash() will use the best one available by default, and if that changes from bcrypt in the future you'll want to make sure you're using it. The hashes are backwards-compatible so you don't have to worry about a hash not working in the future. The $2y$ is how PHP recognizes that the bcrypt algorithm was used to generate the hash. Check the documentation on crypt to see what salts look like: you'll see that the bcrypt ("b" stands for blowfish) salt is formatted as The password "hash" itself is a valid salt, since it was constructed to be salt + raw password hash. To verify a password, password_verify() salts the password using the hash and makes sure the new hash matches the old one. It is as simple as crypt($password, $password_hash) == $password_hash

Did you happen to try with details/message in the order kicken said to use? Because he was right.

No. It was hypothetical. You'd have to make them yourself.

And how about the rest of your code?

Does leaving the UID and PWD empty work? Completely removing them from the array? But you really should set a username and password on the server.

Don't know if I'd call it a "pattern"... I suppose it is, kinda. Consider code like this: function processCsvFile($file) { $handle = fopen($file, "rb"); if (!$handle) { trigger_error("Cannot open CSV file: {$file}", E_USER_WARNING); return false; } $l = 1; $header = fgetcsv($handle); if (!$header) { trigger_error("First line of CSV file {$file} is not a valid header", E_USER_WARNING); fclose($handle); return false; } while (!feof($handle)) { $l++; $line = fgetcsv($handle); if (!processCsvLine($header, $line)) { trigger_error("Cannot process line {$l} of file {$file}", E_USER_WARNING); fclose($handle); return false; } } fclose($handle); return true; }There are three places where errors can occur: when opening the file, when reading the first line, and when reading subsequent lines. For the latter two you should fclose() the file before returning or else the file handle will stay open for the rest of your script. Exceptions make it a bit less obvious that your function can quit early because they can happen at any time: in your code, in the code you call, in anything that code calls, and so on. However you should still make sure to close that file handle. A try/finally lets you keep an eye out for exceptions without forcing you to handle them; processCsvLine() could throw an exception and processCsvFile() may not want to catch it. function processCsvFile($file) { $handle = fopen($file, "rb"); if (!$handle) { throw new FileOpenException($file, "rb"); // cannot open file $file for mode rb } try { $l = 1; $header = fgetcsv($handle); if (!$header) { throw new InvalidFileDataException($file, "First line of CSV file %s is not a valid header"); } while (!feof($handle)) { $l++; $line = fgetcsv($handle); processCsvLine($header, $line); } } finally { fclose($handle); } }Notice that neither of the two functions need to return true/false anymore because "success" is returning at all and "failure" is receiving an exception. A bit too vague for me to make a decision either way but in general I would support that.At least make sure you're using the $previous argument to Exception's constructor catch (PDOException $pdoe) { throw new BusinessPdoException("Message", other arguments, $pdoe); // class BusinessPdoException extends Exception { // public function __construct($message, $other_arguments, Exception $previous = null) { // parent::__construct($message, 0, $previous);so that logging can (hopefully) get the full trace.

If there was a single entry point into the application, such as a "router" or "front controller", then I would catch Exception there for one primary reason: to avoid a white screen of death. Without a single entry point you can use a global exception handler (ie, set_exception_handler) to the same effect. Meanwhile shutdown functions are a bit limited in what they can work with, lest you trigger undefined behavior for instance, so at that point it may be too late to take particular types of actions. I would also catch Exception if there was a place in code that had to guarantee that it does not throw exceptions of any kind. The only place I can think of where that might be the case is inside a __toString(): if you throw an exception from there then PHP will fatal out saying "Method class::__toString() must not throw an exception". Most other cases can be dealt with using a try/finally: try { // code } finally { // clean up after previous code }

Include how? How do you expect it to combine multiple rows of data into one single string?

I don't see why not. Two race conditions, two locks: 1. SELECT/UPDATE race condition solved with a pessimistic lock. I could use an optimistic lock and an UPDATE...WHERE timestamp=X but I'd rather not. 2. "User A loaded page, user B loaded and saved, user A saved" race condition solved with an optimistic lock. Can't use a pessimistic lock between page loads. Fair enough. Version number then, and version++ on save. [edit] Or avoid most of this discussion and use proper versioning with history. [/edit]

Make sure you're using the InnoDB engine on that table. Use locking in a transaction and store a timestamp or version identifier in the table so you know when a row has changed. 1. Begin transaction. 2. Get the timestamp/version and compare to the value you expect it to be. If changed then fail and have the user deal with it. 3. Update the data. 4. Commit the transaction. START TRANSACTION /* get the latest modification time to compare with the value you already have (from a previous read) */ SELECT timestamp FROM table WHERE id = whatever FOR UPDATE /* if there are no changes then save your data */ UPDATE table SET data = value... WHERE id = whatever /* (assuming timestamp has an ON UPDATE CURRENT_TIMESTAMP) */ COMMITOr in case of failure, START TRANSACTION /* get the latest modification time to compare with the value you already have (from a previous read) */ SELECT timestamp FROM table WHERE id = whatever FOR UPDATE /* timestamp does not match. rollback, then deal with the conflict however you want */ ROLLBACK(you could actually COMMIT for the failure case, since you haven't made any changes, but might as well do the correct behavior and ROLLBACK)

Also, textareas are supposed to be for long text inputs. Are you sure you want to deny letting people add newlines? Would a one-line textbox be more appropriate?

Get all three. Then uninstall the driver, making sure it deletes the drivers too, and install new drivers by pointing Windows to the directory where you've extracted all three drivers - Windows will find and install the appropriate one.

$query is just the string SQL query. You want $squery, which is the actual result of executing the query (or at least trying to).

Continuously ping the computer (after making sure it responds to pings). If it drops out then you know there's a problem.

You get the value from $_SERVER. Like you're already doing. With $ip.

Did you do that thing I said to do if you kept getting that error? Unless you want to support multiple sites at once, just put all the files you currently have in websitename/ in the parent directory (htdocs or /var/www or whatever that is).