Phi11W

Store date values in Date fields. MySQL knows how to do "date things" with Date fields, including sorting them. It doesn't know how to do "date things" with Varchar fields. Convert your data [once], store it correctly, and wave goodbye to [almost] all your date-related problems. Regards, Phill W.

. . . And your question is? Regards, Phill W.

Short answer: Your HTML is incorrect. You're missing the closing '>' on the Checkbox's input element. I'd also recommend using quotes on HTML attributes. The cases where you need them far outnumber those where you can get away without them. I'd suggest something more like this: echo '<form method="post" action="#">'; while( $row = mysqli_fetch_assoc( $result ) ) { printf( '<center>' . '%1$s %2$t<br>' . '%3%s %4$s<br>' . '%5$s[%6$s] vs %7$s[%8$s]<br>' . '<input type="checkbox" value="%5$s" name="team"> . '</center>' , $row['data'] , $row['time'] , $row['country'] , $row['lega'] , $row['team1'] , $row['pos_t1'] , $row['team2'] , $row['pos_t2'] ); echo '<input type="submit" value="submit"></form>'; Regards, Phill W.

NOT NULL cannot be omitted if the field must never contain NULLs. Remember that the DEFAULT clause only applies when inserting new records and where this field value is not specified. Including NOT NULL prevents the value from being set to NULL at some later point, i.e. this statement would fail: update .. set quantity = NULL , TYPE = NULL where ... Without NOT NULL, it would work. Regards, Phill W.

If you're using Sessions (not everybody does) you could capture the given QueryString Argument, save it into the Session, then redirect to the same page without the QueryString Argument, this time taking the id value from the Session. This may go some way to achieving what you want: if ( isset( $_GET[ 'id' ] ) { $_SESSION[ 'id' ] = $_GET[ 'id' ] ; http_response_code( 302 ); header( 'location: .../same_page_without_querystring_arguments' ); return; } if ( ! isset( $_SESSION[ 'id' ] ) ) { // No id available! header( 'location: .../errorpage.php' ); return; } $id = $_SESSION[ 'id' ]; // Display rest of page. Of course, it's not foolproof - anything that can be built can be broken and, at the end of the day, the browser simply has to know this value in order to request it! Regards, Phill W.

Which field in Charters identifies the driver in question? SELECT chtr.id, chtr.charter_name, chtr.fleet_number, chtr.driver, chtr.customer_name, chtr.customer_number, chtr.dep_date, chtr.status /* \/ \____/ Which of these is the id into the users table? */ , usr.id, usr.fname FROM charters AS chtr LEFT JOIN users AS usr ON chtr.id = usr.id /* \/ Should this, perhaps, be chtr.driver? */ I would expect every table to have its own, unique id field and those ids are completely independent of one another (by which I mean Charter .id=6 is a completely different thing to Users .id=6). Regards, Phill W.

What does the fetch() function return? I think you need something more like this: $row = $stmt -> fetch(); echo( $row[ 'N1' ] ); Also, avoid using "select *" in Application code. Whilst you might not have a lot of columns in that table [yet], databases are inherently shared entities and you never know when someone [else] might add a dozen columns full of gigabytes of stuff that this query simply doesn't care about. Always select just the columns that you specifically need. Regards, Phill W.

What time does your hosting server (i.e. computer) think it is? That's what the time() function returns and if the clock on your server has "wandered" a bit, you'll get that "wandered" value. If it was out by exactly an hour, either way, I'd be thinking Timezone issues instead. Do you have a working NTP service running on your computer? That should keep your clock properly synchronised with the rest of the world. Regards, Phill W.

This is almost always the wrong way to do things. You cannot guarantee that this update process will run every, single day. This is Technology - stuff happens. Updating every record is a lot of [unnecessary] work for your database to do and will, almost certainly, lock the entire table, causing other issues. Showing stuff to Users is not the database's job. You'll write an Application that the Users interact with and that will show them your "remaining time". I'm sorry, but why? Users these days want instant responses, not arbitrary and artificially-enforced delays. If you are interested in a particular date & time, then work out when that is and store that. You never need to change it, "in bulk" or at all, Your application can calculate how long it is until "Real Time" catches up with it and show that duration to the User, no matter what they do in the meantime (refreshing, logging off-and-on again, etc. ), and You can easily tell once you have reached it in a SQL query. Keep it Simple ... Regards, Phill W.

I would go further and say you must not "select data in order to decide to insert or update it". That road leads to Race Conditions. Whist "on duplicate update" exists and works well, I would suggest making a conscious decision about which is the more likely condition to occur. In this case, I would say that updates are far more likely that inserts (with new pages only being added occasionally) so I would code the update first, and check to see whether zero rows were updated by it and, if so, insert the new row. Regards, Phill Ward.

The path is relative to where it starts from. Without any qualification ("inc/header.php"), it starts from the current directory, i.e. where the file doing the including is. With a leading slash ("/inc/header.php"), it will start at the root of the site. You might also be able to navigate "upwards", e.g. "../inc/header.php", but that's actively barred in some systems and will drive you mad if you have to refactor the site significantly. Regards, Phill W.

Hi Barand, If only for completeness, shouldn't you have a "group by Branch" in there? Regards, Phill Ward.

Five of your queries use "SELECT *". Do not do this in Production code. Databases are intrinsically shared entities and table structures can be changed [by anyone] at any time. Retrieving more fields than you actually need leaves you open to expected slow-downs, not of your making. Your remaining four queries could be combined into two. Taking the first pair, you can retrieve both aggregated values in one query: SELECT date_format(Date,'%Y') as month, COUNT(*) COUNT FROM calibrationdata WHERE Branch = '$userbranch' group by year(Date) order by year(Date) SELECT date_format(Date,'%Y') as month, sum(amount) FROM calibrationdata WHERE Branch = '$userbranch' group by year(Date) order by year(Date) // Can be combined into SELECT DATE_FORMAT( `Date`,'%Y' ) as month , COUNT( * ) as tally , SUM( amount ) as total FROM calibrationdata WHERE Branch = '$userbranch' GROUP BY year( `Date` ) ORDER BY year( `Date` ) Execute the query once, retrieve the values into an intermediate variable, then display that at the relevant point on the page. Also,. make sure that you have a database index supporting querying this table by Branch. Also, take a look at Parameterised Queries (Prepared Statements) to protect against SQL Injection Attacks. Obligatory XKCD Reference: Little Bobby Tables. Regards, Phill W.

Or, perhaps better (i.e. safer) ... switch( $_POST[ 'siti' ] ) { case: 'FIUMI' : case: 'MOLINI' : case: 'VITA' : $category = $_POST[ 'siti' ] ; break; default: throw new \Exception( 'Invalid category!' ); } Why? Just because you send the User an HTML SELECT list to use does not guarantee that the value you receive comes from that list! Regards, Phill W.

How does the User tell your code which "category" a file belongs to? Presumably, that would be another Form field, passed at the same time as the uploaded file itself. [Validate and then] Use that value to construct the target path for the file and pass that value to move_uploaded_file(). // pseudo-code if ( isset( $_POST[ 'btn-upload' ] ) ) { if ( validatePostArguments( $_POST ) ) { $targetFile = buildTargetPath( $_POST[ 'category' ], $_FILES[ 'file' ] ); move_uploaded_file( $file_loc, $targetFile ); } } Regards, Phill W.