[peterlaursen]

.. or as I wrote in the database menu/context menu when a database is selected in Object Browser.

[peterlaursen]

There are 2 ways to import from CSV.

1) Using LOAD DATA LOCAL syntax. When using this option the table must be created in advance (the LOAD DATA statement is executed by the server and does not have an option to create a table – refer http://dev.mysql.com…/load-data.html)

2) Using ODBC (in case Microsoft text ODBC-driver). This tool (named 'Import External Data') can create the table.

If you select a 'database node' in the Object Browser the menu/context menu for 2nd option is available.

[peterlaursen]

A more direct link here: http://www.mysqlperf…t-primary-keys/

[peterlaursen]

yes .. I expected that the file is too big to be loaded into a(n GUI) editor.

But the short answer is that we don't support MySQL before 4.1 anymore. Dumps created with pre-4.1 version of 'mysqldump' may fail to import to later server versions with SQLyog from 8.2x depending on server configuration.

We can provide an old version that will work for this scenario to registered customers. if you need this please contact us at [email protected]. And note that you can multiple versions installed at the same time (installed to different folders).

[peterlaursen]

Not having a Primary/Unique key on a table is a very bad practice. In particular with InnoDB, in my opinion. With no such on tables you may experience some performacne improvement when INSERTing, but SELECTs using non-trivial queries will suffer badly. This is documeted several times by MySQL experts. Last time here: http://www.ovaistari…t-primary-keys/

Since it is a problem for you that connection is lost frequently when executing a long-running query, I think that you should rather focus on resolving this. It is probably a networking issue at your end. We had no other complaints like this before.

As I already told it may as well be a problem (for other users on other environments) if the query is NOT re-submitted. So we have chosen to re-submit the query. We think it is a 'feature' but you are welcome to have another opinion.

[peterlaursen]

Also your last reply, I do not understand. Please elaborate.

Besides your signature here (“The [url= …”) is completely unacceptable here. We don't accept this Forums to be used as an advertisement board. In you don't edit your profile in a few day and remove this you will be banned access to here and this topic will be deleted..

[peterlaursen]

Why not use REPLACE INTO rather than INSERT INTO in the query?

(refer http://dev.mysql.com/doc/refman/5.5/en/replace.html)

[peterlaursen]

Well .. I doubt this this is realated to persions at all.

Maybe you could try on another system/computer? It looks like a very system-specific problem. Also try to reboot the system/Windows and start SQLyog with no other application running. It could be as trival as a bad browser plugin causing this.

[peterlaursen]

Sure we will check this after the weekend.

In the meantime, maybe you could try to upgrade from SQLyog 11.2 to 11.26 (latest).

(to download log in to our Customer Portal at http://www.webyog.com/customer and use the purchase email as ID for login).

Please also detail “I began to experience problems accessing the right click options against STORED PROCEDURES”.

Exactly what problems? What happens (that should not) and what does not happen (that should)?

[peterlaursen]

What is the idea of implementing authentication in *ONE* client when anybody can just use another client? The most 'canonical' client for MySQL (the 'mysql' command line utility) does not even need to be installed. So even non-admin users can use it.

Privileges and authentication rightly belongs on the server and not in the client. Read about it in MySQL documentation: http://dev.mysql.com…ege-system.html

And besides: referencing 'MySQL Administrator' is close to a joke in my understanding. This program has been discontinued for almost 5 years now. And to my best knowledge the successor from Oracle – MySQL Workbench – does not have an option for client-side authentication.

[peterlaursen]

1) It pulls a section/chunk of the log to the client (=MONyog) machine using SFTP. MONyog never uses any clients or utilities on the server machine. The client codes (both MySQL client code and SSH client code) is compiled/linked into MONyog. We also don't use 'top' or similar utilities on the server for OS-metrics (CPU etc.). We have our own code in MONyog (doing basically a subset of what 'top' does).

2) The log chunk received is parsed and inserted into a SQLite (memory) database. So here we have two steps: 1) parsing the log/log chunk from our own code (our parser is mostly based on regular expressions) in order to generate (SQL) INSERT statements (for SQLite). 2) SQL SELECT statements (against SQLite) for sorting, filtering etc. Also the SQLite library is linked into MONyog.

[peterlaursen]

Now .. if there really is a bug in that old version, what can we do except for fixing in next release (if it is not fixed already)?

In principle we only support the latest stable version. Because this is all we can do. If we change as little as a comma in 9.63 code it will not be 9.63 any more.

Was it possible that you could try with latest (11.26)? And also please tell if this crash happens on the same system, with same job and same MySQL servers as before.

I am not sure that we can use a crash dump from such old version at all. We will need exactly the same build environment (compiler version etc.) as on what this version was compiled. And I am not sure if this version is compiled with an old Visual Studio version that we cannot access from our MSDN account anymore. But we will check.

[peterlaursen]

I do not understand. I can edit the value by typing in the in the GRID. But the 'calendar popup' does not support milli-/microseconds. Was this the point?

Alos please tell the SQLyog version you are using?

[peterlaursen]

OK .. Schema Sync may have an issue with milli- and microseconds resolution (as introduced in MySQL 5.6) of TIMESTAMP/DATETIME columns.

We will check after the weekend.

[peterlaursen]

There is this old MySQL bug: http://bugs.mysql.com/bug.php?id=20356 (that was never fixed).

We also have a FAQ: http://faq.webyog.co…-sensitive.html

and a record in our issue-tracker: http://code.google.c…/detail?id=1256

In Schma sync, we are getting the foreign key information from SHOW CREATE TABLE output.

SHOW CREATE TABLE returns lowercase table name in Foreign key constraint if lower_case_table_names is set to 0.

.. so it is basically MySQL itself that is inconsistent and we did not find a workable solution. Anyway we will discuss again what we can do it improve here – or at least provide some sort of warning.

Read about 'lower_case_table_names' in MySQL:

http://dev.mysql.com…ase_table_names

[Author]

Posts