Leaderboard

I'm pretty sure you're encountering https://github.com/mdbtools/mdbtools/issues/312. Good news is that it was fixed, bad news is that it was fixed in mdbtools 1.0.1 and Ubuntu 24.04 currently only covers through 1.0.0. There might be a third-party PPA out there that has an updated version, but I don't know where to look for one. Or you could venture down the path of building it yourself, if you wanted: grab the Ubuntu sources, patch them according to this PR, and build. Or for a workaround, I think you'll be safe as long as you're not SELECTing anything that requires 64-bits of data length - meaning a VARCHAR(16777215) is okay but a VARCHAR(16777216) is not.

Correct. That is an invalid mysql date. You can set a mode of mysql to accept that value, but that is not the way to handle this problem. Instead, make sure that the OTP expiry allows NULL. Then set the value to NULL. Personally, I would not design a system like this. Instead I would have a related table that only holds "events". I will usually have an user_event_type table that has different allowable authentication events. For example: user event type id | Description 1. Registration 2. Password Reset 3. One time Password 4. Login 5. Close account 6. Failed Login 7. Account locked etc. I don't know what your user table looks like but hopefully it has an ID other than "email". I'll assume you do. So you then have a user_event table with a structure like this: id | user_id | user_event_type_id | event_value | status | expire_date_time | created_at 100| 245 | 3 | xyzabc... | 0 | ..... | current_date There are a few reasons to do this. They include: - you have an audit trail of events - MySQL with InnoDB is optimized for insert queries, and they don't reduce concurrency unlike update queries. Instead of trying to overwrite the OTP, you can simply set the status from 0 to 1 (or whatever value you want). You could have several status values if you want fine grain control over the changes in status. Just to keep it simple, if the person logs in with the OTP, then it's used, so you set the status to 0. A subsequent query of "SELECT * FROM user_event WHERE user_id = 245 and user_event_type = 3 AND status = 0 ORDER BY created_at DESC LIMIT 1" will always find the most recent OTP request. You can then compare that with the OTP value. Making event_value a varchar of a specific length is no cost if the field is unused, as varchars will use the bytes required. So if you want to use event_value for additional data, you can do that, but if it's something simple like "login" event, you don't need to use it. Personally I would also have a client_ip field in a table like this, where I use a varbinary field to store the IP. This works for both IPv4 and IPv6 addresses, but there are some tricks to doing that, and it is not specifically related to your question. I mention it just to be complete.

so, i found the problem, with the help of php's error reporting, though the problem is in javascript. you are echoing blocks of static html/javescript using php's heredoc syntax. when I made the test page i used, the javascript was simply in-line. you are using template literals with embedded expressions in the javascript, e.g. ${some_var}. however, in php's heredoc syntax, this is the syntax for a php variable. so, php is putting the last value for any of its variables with the some_var name into the echoed javascript. how i found this is that the embedded expressions in the openUpdateTotalsPopup() javascrpt, for ${width}, ... produced undefined php variable errors. the simplest fix would be to use php's nowdoc syntax. the correct solution would be to NOT echo blocks of static html/javascript, which I see i wrote about in one of your previous threads.

It worked for years even though it's clearly missing a comma at the end of the first line?