[tdunning]

I have had similar problems. My scenario is that I start a database/table copy in one instance of sqlYog and use another instance to monitor progress (select count(*)…).

I minimize both instances, occasionally opening the monitor instance to check on things.

Then I hear the completion noise from the copy, but I can't un-minimize it. I see the original copy dialog, but it is unresponsive. The copy instance doesn't show up in the alt-tab list and the right-button on the task icon does not provide a menu. Killing with the task manager seems to put things right again.

vygi wrote on Nov 19 2005, 07:59 PM:

Recently I've got some similar problems related to the SQLyog (ver 5.0 final) window refresh/repainting.

We have many servers in our office intranet and I mostly have two connections to different hosts using same SQLyog instance, sometimes three. Last week I've opened 4 or even 5, and SQLyog has suddenly stopped window refreshing: just window border was visible and some icons. F5 was executing current query but only result grid was repainted; remaining screen remained unrefreshed: some parts of other windows were visible. Minimize/restore window did not help. I've tried to close single connections (Ctrl-F4) but with no success. After program restart all was fine again.

Few days later I've got exactly same problem again, and again after opening 4th or 5th connection.

I'm using Windows XP Professional with SP2.

Regards,

Vygi

[post=”7938″]<{POST_SNAPBACK}>[/post]

[tdunning]

This bug appears to be resolved as far as my usage is concerned. Escape characters appear to be persistent across sessions for both copy/paste and import and the strange behavior with back-slashes has apparently been tamed.

I have also verified that trailing separators no longer appear.

Thanks very much for the quick fixes.

[tdunning]

Copy/paste to clipboard doesn't seem to work correctly. The line terminator disappears on me and lines are terminated by a comma. Here are some sample lines of output:

“5376”,”20040818004701″,”20040818004630″,”Nbbdabaacaaa”,”no”,”43″,”0.127811517685480″,”1″,”1″,”1428″,”1″,

“5377”,”20040818005201″,”20040818005117″,”Nbccaaacaabc”,”no”,”45″,”0.108615375225070″,”1″,”1″,”485″,”1″,

“5378”,”20040818005201″,”20040818005146″,”Ndcdcbdaabbb”,”no”,”45″,”0.433942686239200″,”1″,”1″,”588″,”1″,

I don't think that the trailing commas should be there. The confusion may be that the comma should really be a field separator, not a field terminator as is described in the copy to clipboard dialog. In any case, if I repeat the copy to clipboard, the newline character is lost and all of the data appears on one (huge) line.

A possibly related issue is that if I enter the escape character as \, then the next time around it will be listed as . It may be that the n that I have as the line terminator is unescaped the next time around and is then shown as a newline which is just whitespace which gets lost. The correct behavior is to unescape when reading the character from the dialog, but then quote or escape the string when writing to persistent storage. Also, if n is allowed as a line terminator, then \ should be documented as the correct way to express the use of backslash as an escape character.

The summary is that it works better, but it isn't fixed. The bug may have been caused by two problems, one of which is fixed. The old problem of completely losing track is better, but the second problem to do with backslash escaping appears to be unchanged.

[tdunning]

I have downloaded the beta and it does seem to work better.

More testing is still in order to fully confirm that this bug has been fixed, but it looks good so far.

[tdunning]

This problem occurs with any CSV export operation and it is worse than just not saving values between sessions. Values are lost even during a single session.

This is very annoying and causes data corruption if the user doesn't make absolutely sure that all of the values are correct. Since it is common to export data and then repeat the operation (either on another table or on the same table after a tweak), and since it is very reasonable for the user to presume that the values have been saved, this isn't very surprising. The consequences of not having a line or field delimiter is pretty dire.

This should be a pretty high priority bug.

[Author]

Posts