[peterlaursen]

Personally I think that an option to hide the icon bar is an OK request for small devices/screens in particular. This will leave more room for the editor and/or datagrid

 

Except for the exectue/arrowicon i rarely ue iconsmyselt.  I use the menu/context menu mostly and additionlly a few keyboard shortcuts. 

[peterlaursen]

It could be a bug in the server with connections that have been open for a long time.  What is the server version? Execute “SELECT version();” to see all details.

 

When the “query comes from a browser” are you then using a PHP script? PHP will (typically) open a new connection for every query, so with PHP connection are only shortlived. That could explain why it is not affected. SQLyog will keep the connection open and ony if it has been idle for more than the server ‘wait_timeout’ setting, the connection wil be closed (by the server). Default ‘wait_timeout’ setting is 8 hours.

 

(BTW: do you mean “Stored Function” or “User Defined Function” – refer https://dev.mysql.com/doc/refman/5.6/en/udf-compiling.html)

[peterlaursen]

Thanks a lot!

 

You have posted a few feature requests last week and during the weekend, I know. We will reply to those (in this week probably).

[peterlaursen]

There is no way.  This would require a SQL parser inside SQLyog. This would be a huge task as it would have to be written from scratch, since we cannot clone the parser code from the server (for license/legal reasons). 

[peterlaursen]

Could you please try to

1) turn off ‘session restore’. Just in order to find out if it is is related. You do from menu .. tools . preferences .. ‘others’ tab.

2) temproarily turn off what AV/security software you are using. We have some examples that some (one is NOD/ESET) over-agressively prevent writes to user’s “user profile” – in particular if it isbinary writes (and not plain text).  ‘session restore’ and ‘autocomplete’ data are binary SQLite writes. If it is AV- related please tell what you use of the kind and also ensure that you have the latest updates (signatures etc.). 

 

 

What was your old SQLyog version, BTW?

[peterlaursen]

The term “Transact-SQL” does not apply to MySQL. It is the MS SQL ‘SQL-dialect’. 

[peterlaursen]

There is only the option of storing the MONyog /data folder in one place  and no option to ‘split’/divide it into several volumes.

 

But you can edit the /data path in MONyog.ini to point to another volume than where MONyog is installed. To do so:

1) stop MONyog

2) edit MONyog.ini and copy the /Data folder to where you have specified.

3) start MONyog again.

[peterlaursen]

In between, could you please try to REPAIR TABLE or OPTIMIZE TABLE (REPAIR for MyISAM tables, OPTIMIZE for innoD:cool: for affected table(s). This will defragment table files and rebuild indexes. In particular with MyISAM you should expect to do this from time to time. I have seen recommendations to REPAIR MyISAM tablse once per week (though this is properly ‘overkill’). You may also try to back up the table(s) wiht another tool (mysqldmp or whatever) and see if it makes any dfference. 

 

In order to communicate details for the shared session privately, please send a mail to [email protected] with a reference to this discussion. 

[peterlaursen]

OK .. we will try hard to reproduce this.

 

Are you wiling to have a shared session sometime next week? We may need that and we may even need to run some special debug build on your environment to figure out why it is happening.

[peterlaursen]

Please tell: do you experience this with more than one server (in case you have more)?

 

I wonder if it could besome memory exhaustion on the server causing swapping or some user quota being exceeded.. Please try to reduce the CHUNK setting – refer http://faq.webyog.com/content/24/101/en/about-chunks-and-bulks.html

[peterlaursen]

What you have observed is per design.  And I/we have replied the same many times here already. 

 

Data Sync uses the Primary Key of every table to identify if rows are identical or not.  If the value of the Primary Key for a specific row is the same they are considered identical and source will overwrite target for that row. That is the purpose of the Primary Key in relational databases really: it is a unique identification of a row of data. 

 

Consequently, if you want to INSERT randomly to both databases between sync jobs, you will have to define the Primary Key in such a way that the same PK-value is not created on both source and target.  There are at least two ways to do this:

1) Configure servers to use auto_increment_increment and auto_increment_offset values so that (for instance) *odd* PK-values are created on one server and *even* values on the other (this requires that the Primary Key is an integer, of course, and can be difficult to do if you already have data that need to be reindexed asitmay break Foreign keys to do so). auto_increment_increment and auto_increment_offset options are available in MySQL for use with master-master replication primarily, but work equally well with data sync. The scenarios are also quite similar.

2) Add a ‘dummy’ column to every table with different default value on both servers and add this ‘dummy’ column to the Primary Key.

[peterlaursen]

You can open the ’emergency-saved’ session from the menu .. file .. open session savepoint. The file was saved to your ‘user profile’ (C:Users{user}AppDataRoamingSQLyog). I don’t remember the filename but will inform shortly. 

[peterlaursen]

LOAD DATA is executed server-side and not inside SQLyog.  So this request should go to Oracle/MySQL and not to us. 

[peterlaursen]

First  all: your link does not work!

 

Please tell: what localisation(s) do you have of Windows and Office? English only? It looks like the truncation happens inside the ODBC driver where it is assuming “.” as decimal sign (and not “,” as used in most non-English speaking countries). 

 

Anyway .. we will check this and see what can be done. 

[peterlaursen]

My mistake – I only checked the first column of the table.

 

But there are several tokens/words we treat as “keywords” that are not “reserved words”. USER is there because in statements “CREATE USER .. ” and “DROP USER .. ” for instance, “USER” is part of the SQL statement syntax. “reserved words” are words that the MySQL parser needs to be sure is part of statement syntax. This is the same in any programming langue: they all have a number of “reserved words” that the compiler|intepreter|parser *must* use. Without “reserved words” no computer language would never compile|interpret (and run).

 

Our “keywords” are stored in a file named “Keywords.db” – they are not ‘hard-coded’ in the program code. This file is located in the installation folder and is a SQLite database. You can see what is in there and you can add your own if you want and also remove those that you don’t want by editing the file in any SQLite client such as this one https://addons.mozilla.org/en-US/firefox/addon/sqlite-manager/ for instance. Note that everytime you install an upgrade it will be overwritten (so if you edit the file, keep a backup).  

[Author]

Posts