[nithin]

Hello,

There's a small correction in previous post it's not system.dll, it was system's dll. For your case the crash dump pointed to nt.dll.

Anyway please try version 8.16, and lets know the status.

Regards

Nithin

[nithin]

Hello,

I'm sorry to tell you that we don't understand the exact problem you are facing.

From the 1st post we understood like that you wanted to sync your databases but the schema is not same, So my colleague suggested you to use the Schema sync tool to make the schema(source and target) same.

But your last post I didn't understand clearly, Do you want to drop the target database and sync? If so what makes you to do like that? Is it because the schema are different?

please explain the issue in detail step by step so we can help you and provide you the solution quickly.

Thanks

Nithin

[nithin]

Hello,

We will discuss about the feature you suggested after releasing 8.13 and will update here.

Thanks

[nithin]

Hello

We will add an option for pageant , so that user can specify the source of keys.

I have added this to our issue tracker.

http://code.google.com/p/sqlyog/issues/detail?id=1116

We will update the status once we discussed.

Thanks

[nithin]

As a workaround execute this query from SQLyog editor once connected to the server.

set @@session.wait_timeout = 28800;

The session wait_timeout can overirde the 5 second timeout set for the server. But this query is required for each time when SQLyog connected to server.

Please tell this workaround solves the latency issue or not?

Thanks

[nithin]

Thanks for quick response.

From the output of SHOW VARIABLES LIKE '%timeout%' I understand the wait_timeout set for 5 seconds. It means if SQLyog idle for more than 5 seconds It needs reconnection for the next query to execute. With current implementation the reconnect functionality always requires reconnect to server and re-initializing plink. We already told that we are in progress of improving this reconnect operation that doesn’t need re-initializing plink(if no network issue happened) and also reconnecting the sever using MySQL APIs, and I hope this will solve the latency you are facing.

We can provide you special build probably by 3 – 5 days once the development is over.

I will update the status here.

[nithin]

Quote:

Does the Linux version of SJA issue a return code on errors? I am scripting an automated update and need to be able to tell if the process has errors or fails in any way. Is there a return code to check, or a list of possible errors that will be logged, so I can have the script notify me on failure?

Linux SJA logs error to a file 'sja.log' that creates where the SJA.EXE runs. This is similar with Windows when SJA.EXE runs through command line.

If run through SQLyog wizard you can specify the path of sja.log where GUI provides an option for that(please see the screen shot attached)

Thanks

[nithin]

Hello,

Thanks for posting, and its a valid request.

Currently while UPDATE we are SETting all column values, and use the PK column in WHERE clause if its present, otherwise use all columns in WHERE clause.

We should SET only column(s) those are edited, in UPDATE clause .

I added this to issue tracker

http://code.google.com/p/sqlyog/issues/detail?id=1063

We will look into this issue after 8.1 GA released and update the status here(probably next week).

Regards

Nithin

[nithin]

Hello,

This issue is not reproducible at our end, still we are trying.

In between we also like to know some more information that help us to analyze the issue and solve it quickly.

1. For you this issue only happens when 'Export As' as CSV? Or Also Is it happens you like when save the main editor content?

2. Does this issue happen with a particular table or all tables?

3. How many rows you have for that table to export?

4. Can you please try this case with a small table?

5. Also please confirm you have enough memory where you save(please try once with other than 'C' drive)?

Please let us know the details.

Thanks

Nithin

[nithin]

Hello,

1.

Quote:

I'd like to request there would by very appropriate to add schema name before procedure/function name in CREATE

A very important request and I understood its importance. But there is some limitations to prefix by 'schema name' since this CREATE statement is getting generated by issuing the query “SHOW CREATE PROCEDURE `md_REPMOD_getFromQueue`”. MySQL returns this without schema name. And considering of parsing this result to add schema name might be a complex task also. I feel adding query “USE database ” to the top of this Alter procedure statement can solve the issue. We will try for a better solution.

2.

Quote:

grants should be placed after procedure/function is created:

And another valid request. This must be handled because we do 'DROP Procedure' before Altering it which removes all the privileges related to that. We must handle this situation also.

3.

We haven't removed the 'Trigger' in latest versions, I remember since version 7.x we changed its position from under 'table' to under 'database' because Trigger is basically Database object not Table object.

4.

Quote:

We many times receive “MySQL server has gone away” error

We are not sending query 'set wait_timeout' when connection is established from client side. And in btw whats the 'set wait_timeout' value for your server?

Please tell what type of connection you use, direct , remote, HTTP(If you use Enterprise version)?

We will discuss these points (mainly 1 & 2) .

Thank You

Nithin

[nithin]

Hi,

I think still this script got corrupted a bit. Please confirm once again the latest script you attached that you didn't edit anything?

Please see this line in the latest script

Quote:

CONSTRAINT `fk_station_location` FOREIGN KEY (`StationLocation`) REFERENCES `location` (`RegionCode`) ON UPDATE CASCADE,

I can't see column 'RegionCode' in table 'location' ( 'location' has got a PK column 'LocationCode')

While importing, table 'location' is created before 'station'. Since the parent table ('location') present without column 'RegionCode', the creation of 'station' table fails if you specify CONSTRAINT with a non-existing column of 'location' table.

Of course if 'station' table comes prior to the 'location' table in the script, the table 'station' will be created successful with 'SET FOREIGN_KEY_CHECKS = 0' on top of the script (But still 'location' will fail this time). But that kind of reordering is not required here if you would not have edited the script manually.

And I changed the above CONSTRAINT line like this and will be able to import the script successfully.

Quote:

CONSTRAINT `fk_station_location` FOREIGN KEY (`StationLocation`) REFERENCES `location` (`LocationCode`) ON UPDATE CASCADE,

So you also can try this once.

I also suggest do a fresh EXPORT with 'SET FOREIGN_KEY_CHECKS = 0' option selected, and there is no possibility of failing 'Import' process as far I know.

Let me know still if you have any issue?

Thanks

Nithin

[nithin]

SET FOREIGN_KEY_CHECKS = 0 option doesn't make any change in order in the script except it adds a statement SET FK_CHECKS = 0 on top of the script which handles the Table dependencies while importing ('Restore From SQL Dump) the script.

I repeat, While exporting we are not checking whether its lookup table or primary table. We add the statements to script in the order the MySQL returns result for “show full tables” (Usually MySQL returns table names in Alphabetical order only).

Please confirm after checking the 'SET FOREIGN_KEY_CHECKS = 0' option 'Import process' is failing or not? If its failing you may need to attach the SQL dump so that we can reproduce at our end and solve quickly.

Thanks

Nithin

[nithin]

Hello,

Quote:

the script generated did not put the lookup table first before the primary table.

Please tell me why you need in such order? Have you faced any problem while importing the generated script? If so you can do the step I described below Or please explain where you faced the difficulty?

While exporting we are not checking whether its lookup table or primary table. We add the statements to script in the order the MySQL returns result for “show full tables”.

To avoid the table dependencies that may happen while importing the SQL script, you must select the option 'SET FOREIGN_KEY_CHEKS =0' in the dialog of ” Backup Database As SQL Dump” before exporting.

Thanks

Nithin

[nithin]

Hello,

Please go to tools -> preferences -> Others – 'Data display/editing' section and check ‘Automatically refresh DATA tab on focus’

Change logs for 7.1 read:

* Added an option in Preferences to ‘Automatically refresh DATA tab on focus’. This was the program behavior before 7.0. In 7.0 to 7.02 it was not. Now it is optional.

Let me know this solves the issue for you?

Note:

This is basically the principles of communication between a SQL server and client: All data are *on the server* and there is only one way to communicate with that server: by using SQL statements. When you select Data tab, SQLyog will send a SELECT SQL-statement to the server and the server will send what is stored in the database. You can see the SQL-statment in the HISTORY tab.

[nithin]

Hello,

This issue has been fixed and released SQLyog7.11 yesterday.

http://www.webyog.com/blog/2008/09/29/sqly…-been-released/

Please make sure the issue you found is fixed here.

[Author]

Posts