[peterlaursen]

The MONyog interface displays the version in the upper left corner. 

 

We will add a –version/-v switch so that you can verify the version from commandline as well.

[peterlaursen]

The only way to downgrade is start MONyog with an empty MONyog /Data folder (in cases where the schema of the MONyog embedded database are different between the 2 versions).

 

You may refer http://blog.webyog.com/2009/07/29/monyog-database-schema-explained/ :

“There is a schema_version table in all databases created by MONyog. Every time MONyog starts it will check here if the database is up to date with the current program version. If it is not MONyog will perform the necessary schema upgrades at start-up. Schema definition reads:”

 

But there is no logic handling downgrades a similar way. And that is why you get the errors in the log.

 

 

You write “So now I need to test the downgrade path in case we have issues in production with the new version.”.  Don’t worry! You will nto face issues!

[peterlaursen]

And we have a FAQ as well:

http://faq.webyog.com/content/17/187/en/problems-creating-a-functional-dsn-on-64-bit-windows.html

[peterlaursen]

I have added a reference to this discussion to our issuetracker here:

https://code.google.com/p/sqlyog/issues/detail?id=45

[peterlaursen]

I understand that you are referring to the filter in Object Browser? Please confirm.

 

It will display the first match (alphabetically) and I don’t think there is any change in this respect for the very beginning where we introduced this. 

 

I realize that this is inconsistent with the behavior of auto-complete in the editor (where a match will only display when there is only one possible match). I think for most users current behavior is convenient, but if you have a lot of database objects in same level named with same initial letters (mydb1, mydb2, mydb3 etc.) you may experience what you describe.

 

Personally I agree that this could be implemented better.  I have added an issue in our issuetracker at https://code.google.com/p/sqlyog/issues/detail?id=2037. We will discuss this.

[peterlaursen]

For completeness: In both visual and non-visual mode of Data Sync the WHERE option is exectued on and not on

[peterlaursen]

We have this recorded here already:

https://code.google.com/p/sqlyog/issues/detail?id=1852

(where I added a not to this post as well).

 

We should fix the compiler errors on VS 2012, but for the next weeks or months it is not priority.

[peterlaursen]

Well .. it creates fine in SQLyog as well (on MySQL 5.6.17). 

 

The “Query Browser” tool from MySQL/Oracle is an old tool now and not supported any more (it was not for around 4 years). But the error is returned from the server.  But it can be hard to determine where the actual error is – it may be the line you mark as red – but it could be the line before as well. One option could be the (brackets) used in identifiers. What is the server version? (execute “SELECT VERSION()” to find out.

 

If command line works and QB does not to same server it looks like QB has problems with this statement (and the only thing that is unusual is the use of (brackets) in identifiers. Or possibly the DELMITERs

 

 

Besides .. if you have questions/problems wiht Query Browser, this not the best place to ask.  We support our own programs (SQLyog and MONyog) only.  You are still welcome to ask here, and some other user may know about it – but it is still unlikely.

[peterlaursen]

.. but an ENUM is a *string*.  It works if you have a list of strings (that is not containing too many values) that you want to restrict.

 

It will not really work with numbers.  If for instance you want to restrict a DECIMAL to the range (>0 AND <50), there is not really a server-side solution.  You will then need to add the validation in your application.

[peterlaursen]

No there is not.

 

The MySQL server does not support CHECK CONSTRAINTS. You may specify it in CREATE/ALTER TABLE, but it is simply ignored (and not returning neither an error nor a warning).

 

https://dev.mysql.com/doc/refman/5.5/en/create-table.html says shortly

“The CHECK clause is parsed but ignored by all storage engines”

 

You can also search for it in bugs.mysql.com. It has been reported several times there. But currently it is not supposed to work with any MySQL server version.

 

A workaround is to use an ENUM field. Refer https://dev.mysql.com/doc/refman/5.5/en/constraint-enum.html

[peterlaursen]

It definitely DOES install on (most, at least) Win7 and Win8 systems! 

 

Please do not assume that a specific problem on your environment is a general problem.

[peterlaursen]

One more detail: please check the Windows ‘Event Viewer’ for details why the job was terminated.  You find it in Control Panel .. Administration .. Logs .. ‘applications’ group (it differs a little between Windows versions and localizations).

 

Please locate any record here with ‘sja.exe’. It is not very informative what you find there, but there should at least be an error code.

[peterlaursen]

Please read this FAQ:

http://faq.webyog.com/content/27/34/en/why-is-my-scheduled-job-not-running.html

 

Now this FAQ was originally written for Windows 2000 (where the schduler had a lot of issues).  I have actually being considering to hdie it, as I though this was not relevant now, where we do not support Windows 2000 anymore.

 

 

But I think the following qustions are still relavant:

 

1) Does your user account use a password?

2) Are you an admin user?

3) Is UAC (User Account Control) enabled?

[peterlaursen]

It is encoded using the same obfuscation algorithm as used for stored connection authentication details in “SQLyog.ini”.  What it is, is not a big secret. If you read C program code you can find the algorithm in the source code of COMMUNITY version. But we still do not want to elaborate in public as it may be misused.

 

When generating job files, the GUI wizards will obfuscate the password. This was introduced a few years ago.  Before that passwords in SJA job files were not obfuscated. In order to still be able to run jobs generated with older versions (or using hand-written jobfiles) we introduced the XML tag (or ).  If there is not such tag at all, “no” is default, so if this tag does not appear in the job file SQLyog/SJA will read the password as clear text.

 

If you have a job file with , you may simply delete that tag (or change “yes” to “no”) and write the password in clear text.

[peterlaursen]

Well .. I think that a popup dialog (or any similar solution) would be equally or even more annoying for lots of users. confirm .. confirm .confirm. I basically HATE programs asking me to confrimn every time I do something! 🙂

 

What I could suggest is a STOP option somehow (for instance a button placed on the tab itself if this is possible). What say?

[Author]

Posts