I get the same issue here - but it only happends where date fields have null values. Previous version of Toad had no trouble with this, though; I keep 4.6 around for this reason. 4.6 just seems to substitute 1/1/0001 to display null value dates in the grid.
I had my PC re-masterized by IT services and had the same issue after installing the new version of Toad for MySQL. I confirm that apparently, the tool is sticking much more with the table definition which makes this kind of errors appear when you have "NOT NULL" columns with "NULL" values.
I truncated my table, changed the definition of all my dates where I know there could have null dates and re-imported the data again.
Since then, no more issues with Toad!
Also, I'd like to add that now the "Import" tool is working just fine (with a huge CSV file of 150Mb) while it was always crashing the software at the end with the previous version ;)
I'm not too sure that the columns are literally NULL, as in the MySQL standard representation of NULL, but they are tantamount.
In the MySQL client, the problem rows had the TS of 0000-00-00 00:00:00.
I'm not sure if something lime 2010-00-00 is allowed.
The problem is Toad is just tossing the date part straight into a standard calendar LIB.
That's not going to work for a month/day of 00 because you don't even need to do a Gregorian Calendar check to validate that. A month cannot be Zero.
The year of 0000 may fail because usually computer dates don't like to go lower than 1970 (By the Silicon Calendar it is currently the year 40).
The obvious solution, is that it should behave like it would a column that allows NULLs as you have pointed out. That is, you can set to a calendar date, or set to a blank date of 0000-00-00 00:00:00.
If 2010-00-01 is allow or similar, then the calendar would want to be able to represent that with and extra special month of "??" in my opinion, which would potentially be better than 00 as 00 may confuse people into thinking that's where the month offset starts from (ending at 11).
Even if the calendar API doesn't allow you to set some dates like that, Toad must be able to display those columns accurately.
I actually was using the Beta version (6.0) because of this and was very happy. But now after using the beta for so long it says something to the effect the 'Beta period is expired' and it sends me to download 5.0 again. I have never seen a beta that expired ... When is this beta going to be GA so I don't have to deal with 5.0 anymore (too many bugs)
Yes, that is what we are doing however since this does actually change the value you see in the grid a warning that this has happened whenever we read one of these values (That is what you are seeing in the output tab) so this is the expected behavior.
It changes the display of the value -- to blank, like other valid cells -- and does not indicate a problem, nor tries to fix it, nor shows in the output which cells or rows these may be, just their column names.
Contrarily, SQuirreL at least shows these cells as <Error>, but it does not let me fix them -- so presently, I am finding all of these <Error> cells in SQuirreL, finding them again in Toad by ID, editing a random cell in that row with Toad, and editing it back with Toad, so the cells are just nullified, as they are causing issues elsewhere.