[JimZ]

peterlaursen wrote on Oct 25 2007, 03:25 AM:

Please read:

http://webyog.com/faq/content/8/99/en/does…l-keywords.html

http://webyog.com/faq/content/8/116/en/can…sult-panes.html

That says nothing about using MySQL functions in a column default. It's a MySQL limitation, so there's no way that SQLYog can get around it. Thanks anyway.

[JimZ]

Ok, I found the answer… I guess you _can't_ use a MySQL function within a default, with the exception of using CURRENT_TIMESTAMP for a timestamp field.

[JimZ]

peterlaursen wrote on Sep 6 2007, 03:44 PM:

I do not remember details but FLOAT type implementation has changed with different MySQL versions. I think what was earlier (4,2) may be now (6,2), but not sure. We will check this of course! We will prefer to solve it and not display warnings!

I do not consider this an emergency however!

No, no longer an emergency. Thank you very much for the quick replies.

Quote:

BTW: I do not understand why you do not use DECIMAL for money! That is actually what it is intended for primarily! DECIMAL(19,4) is commonly used (4 digits after decimal sign is normally what is required to compesate for rounding errors) for MONEY.

I'm afraid I didn't design the database.

What happens if you alter a table from SQLYog, changing the FLOAT columns to DECIMAL? Will the data be correctly preserved?

[JimZ]

I was able to fix the problem. Instead of the using SQLYog's copy function, I dumped the database using mysqldump.exe and then imported it using SQLYog. When I attempted the import I got an error message about an out of range value.

So I edited the dump file to make the two 'float (4,2)' columns just simple 'float' columns and was able to successfully import it.

So there's seem to be problems with the copy feature. I think these were the only column using that data type spec, so hopefully all the other data made it across OK. There needs to be some kind of error message in the copy function and perhaps some additional options, such as whether to continue and how to handle values that throw errors.

[JimZ]

Funny… I searched the forums with the same question and found this thread, only a week old.

If you use a keyword, then no matter what you decide, with you _will_ need an escape mechanism, or else you end up with an inconsistency. If you want to use the keyword EMPTY, then users have no way of entering a default of the actual text string 'EMPTY'.

And if you use a keyword, why not use the keyword NULL? When someone creates a new column (or changes the column datatype), automatically populate the column with the word NULL. And use some escape mechanism such as NULL or similar to actually indicate the string 'NULL'.

Currently, you seem to have conflicting behavior. I see an empty column under default, yet I end up with NULL as the default. That doesn't make sense to me.

[JimZ]

peterlaursen wrote on Feb 4 2007, 10:17 PM:

not quite.

http://dev.mysql.com/doc/refman/5.0/en/sto…quirements.html says

“Prior to MySQL 5.0.3: L + 1 bytes, where L <= M and 0 <= M <= 255. MySQL 5.0.3 and later: L + 1 bytes, where L <= M and 0 <= M <= 255 or L + 2 bytes, where L <= M and 256 <= M <= 65535 (see note below)." note 1) the limitation is in bytes not in characters. So it depends on the character set …

2) “<= 65535" refers to the storage. Some of those bytes are needed for internal adressing inside the tablespace.

Here I can create a varchar(65500) with a latin 1 table. Won't that do for you?

Ok, that makes sense. I thought it was characters. The table type is utf8, so I suppose they figure up to three bytes per characater. The max lengtht that I can declare is 21843 characters.

One odd bit of behavior, however is that within a certain range I receiver error no. 1118 about the row size being too large. If I try a larger value for the varchar size, SQLyog doesn't complain, but the row is automatically set to mediumtext.

[Author]

Posts