Nasty Bug Found In Text Entry: V5.14 And V5.15

[mattRobertson]

If you put the string 'Default' into a varchar field the most recent versions of SQLYog will turn the field contents into a null value rather than saving the string “Default”. You have to move away from the table data view and come back to see it, as SQLYog will spuriously show the data in the field — although your data has already been corrupted and the string no longer exists — unless you force a view refresh of some sort.

My copy of v5.02 Enterprise behaves properly. I'm going to have to try and install that rather than buying new copies as my CMS uses this string in critical areas. That or use a competing product.

Also my resellers need something to view my mySQL db's with and this bug puts you out of the running as a recommended solution.

Is there any way to get hold of an older working version? If not I have to drop your product from my recommendation list. I'm dead otherwise so I have no choice.

[peterlaursen]

it is all explained here:

http://www.webyog.com/faq/8_99_en.html

I think your column is defined as DEFAULT NULL ?

For those few words that are KEYWORDS, you must enclose the string in backquotes like `default` .

[mattRobertson]

peterlaursen wrote on Jul 19 2006, 05:34 AM:

it is all explained here:

http://www.webyog.com/faq/8_99_en.html

I think your column is defined as DEFAULT NULL ?

For those few words that are KEYWORDS, you must enclose the string in backquotes like `default` .

Yes that fixed it. Thank you!

So if you ever edit a record with one of these values in it, SQLYog will assume you want its SQLYog-specific behavior and — if that assumption is incorrect — corrupt it. And this is by design? I have a GUI so I can edit the data myself, not so something can decide to edit it for me. If there is no way to turn off this behavior I could wind up corrupting any database record I touch. I go into client systems every day and many times I haven't got a clue whats inside until I look. I can't just go in and change a field that needs it anymore as SQLYog could break the record? Thats not something I should ever have to worry about from a DB GUI.

In the case of the cms I am editing, thankfully I don't use this so much that I can't provide some instruction to work around it. But this is a built-in way for your product to crash the client's entire application if they forget that instruction.

I can see where the words other than “default” are highly unlikely to see themselves placed as standalone values, but “default” itself seems mighty common, and its of course not a reserved word in mySQL itself.

How can this be disabled? Honestly I have never heard of a db fornt end that will decide for itself what it will do with existing data that it wasn't expressly asked to alter by the user, and am a little dumbfounded to find out the behavior was deliberate.

At least put in a switch somewhere in preferences!

[peterlaursen]

Quote:

At least put in a switch somewhere in preferences!

We will discuss that.

BTW: Please observe too that also functions are evalutated.

http://webyog.com/faq/8_116_en.html

[mattRobertson]

peterlaursen wrote on Jul 19 2006, 04:10 PM:

We will discuss that.

BTW: Please observe too that also functions are evalutated.

http://webyog.com/faq/8_116_en.html

Hopefully nobody has something like that in a data field. It is unlikely but nothing is impossible.

I would suggest the default behavior is to shut this feature off, since it can — and in my case did — result in data alterations without any direct action on the part of the developer. If I hadn't had a freebie 5.02 sitting on another machine I (or more accurately my client) would have been out of business until I wrote and ran manual SQL queries to replace the destroyed data. It doesnt' take long to write a query but it took a couple of hours to figure out which of the dozens of tables was throwing an error and why.

[Ritesh]

We will put that as a preference in the next release.

[Author]

Posts