I think that's just lazy. If you really want to convince customers that your system is the best for database design/layout, I think you're going to have to do better than that.In particular with regard to your support for MySQL which is the most commonly used database and not some obscure product hardly used.

How hard could it be to actually implement such a feature in the GUI (a pair of radio buttons which default to the chosen database's default would be the correct way) and the required  back end code. Not very is the answer.

That's what I love to hear :-)

Actually, it's not just fixing the bug that erroneously flags an ENUM field as not supported by MySQL, but rather that Vertabelo needs to actively support their use. IOW provide a suitable area to enter the options rather than having to stuff them in the column name field.

Same goes for SET data type. 

Seems to me a bit fundamental that Vetabelo cannot handle all the data types supported by the chosen database. Turning  "Supported database type (warnings)" off is not really a solution since that would then stop any real errors being flagged.

When will this bug be quashed?

Hmm, that doesn't seem very satisfactory. Specifying SIGNED or UNSIGNED should be a simple checkbox. What's the default if you don't specify?

Fair enough. I look forward to it. Safari on the iPad - Yay.

Thanks for the response. I look forward to Safari compatibility.

As for touch devices, why not? Not perhaps in isolation as I quite understand the importance of larger screen etc, but the ability to log in and look at the model and make small adjustments from such a mobile device would be extremely useful and I would have thought a fundamental reason to choose a web based system.

Why wouldn't it work with a touch device? Fingers are clumsy for intricate work I agree, but use of a stylus of some sort usually fixes that. I still think being able to edit a diagram on the iPad would be invaluable.

No response?

No-one cares?

Google Chrome says I need to use Google Chrome. Isn't that worthy of some comment?

That's how I ended up doing it, but it's a convoluted process. Far better if there was an option to simply change the database and then just report the errors, as when importing it in the method outlined above. 

Essential I'd say. Wish I could turn it off in Google Maps, it's a nightmare.

Anyway, could we also have an option to allow scrolling instead - that's what mouse scrolling should be used for.