[Lazarus] Lazarus, Jedi etc.

[Ludo Brands]

On 07/15/2013 05:53 PM, Graeme Geldenhuys wrote:
> On 2013-07-15 16:40, Henry Vermaak wrote:
>> If you want an INSERT statement to generate an error unless you
>> explicitly specify values for all columns that do not have a default
>> value, you should use strict mode."
> 
> 
> And G*d only knows why they have such modes in the first place! You
> would think that if they do value data (what you put in is what you get
> out), there would only be 'strict mode', or at least make that the more
> sane and default mode. Like I said, I installed MySQL on FreeBSD from
> source code and didn't customise any settings.
> 
> The case sensitivity in the table names is also crazy, especially if the
> database gets moved. I had to modify quite a lot of SQL statements
> because of that. For MySQL support I had to look up the table name (as
> MySQL has it), then modify lots and lots of SQL in my application to
> match that case exactly. Crazy stuff!
> 
> Regards,
>   G.
> 

Need other default (mis)behaviors for MySQL?
-insert "123test" in an integer field: no error, it inserts 123
-insert "123test" in a datetime field: no error, it inserts 0000-00-00
00:00:00
-insert 123 in a datetime field: no error, it inserts 2000-01-23
00:00:00 . Yes you got that right, inserting integer 11231 translates in
2001-12-31 00:00:00. 11232 gives 0000-00-00 00:00:00 again. Insert
11231.133 and you get 2001-12-31 00:00:00 again
-now that you understand the integer to datatime mapping do an UPDATE
table SET date=date+4, you get 2001-12-31 00:00:04. UPDATE table SET
date=date+400 and you obtain 2001-12-31 00:04:04.
-UPDATE table SET date=date*2 results in 0000-00-00 00:00:00. No error.
-more MySQL arithmetic: insert "2001-1+10+3" into a date field: You get
2001-01-10 03:00:00. "2001-1*10/4^2" results in 2001-01-10 04:02:00

Throw anything at it and MySQL will swallow. Your data are in good hands ;)

Ludo