Forum Replies Created
-
AuthorPosts
-
Ritesh
MemberVery strange. I am not able to reproduce the column truncation error.
MemberQuote:When you use SQLyog to make a copy to a different host, it may say that everything is “OK” when really it is not ok if there were a problem that perhaps the program could not detect.Very strange. What kind of error you suspect that might occur?
Quote:A problem of SQLyog is that errors are written in a file stored in the Program Files folder, and errors appended to others and it is not easy to know when an error was written.Whenever SQLyog comes across an error, it will display a MessageBox notifying you about it. Starting from v4.07, the error dialog will also have a button to open SQLyog.err.
Quote:Then I disconnect the new host database and connected again, and for this specific database (posts) it showed the same qty of records from the current database and both dumps.You mean to say that just reconnecting to the new hosts solved the problem?
Is it possible that you upload the dump at one of your server from where we can download it? 90MB download should not be a problem.
MemberVery good.
We plan to release v4.07 FINAL this week and then v4.1 BETA 1.
MemberThanks for the feature request. I have forwarded your issue to my development team.
MemberMemberQuote:Since it will ALWAYs use the PK-column(s) I don't see why I should need to specify it.SJA always uses PK columns to get the unique row. If you dont specify the PK columns then those columns wont be used while generating checksums.
Quote:In this case I ONLY want to use SQL_WHERE. SJA should generate checksums only on rows that satisfy the SQL_WHERE condition (besides using the PK as it must do).It only uses the rows satisfied in the SQL_WHERE clause but you have to specify which columns to use to generate checksums.
Putting it succinctly:
PK columns are used to select the unique row. Selection of columns tells SJA to use specific columns for generating checksums. Since checksum generation is a CPU intensive work, you can skip BLOB columns if possible.
Memberpeterlaursen wrote on Jul 3 2005, 11:19 PM:Quote:It wont make any difference as SJA will search for the primary key columns in the tables.The GUI functionality does not seem to know that! If NO colums are selected it displays this error msg. Choosing the PK-column (and that alone) works fine (with SQL_WHERE operating on another column)!
This behavior is correct. You have to atlease select one column to generate checksums to find the difference. What I meant is that you dont need to necessarily select a PK column in this list.
MemberThanks for the info.
MemberQuote:Seems very good to me (but a bit expensive at $199) Would be interested in your comments/experiencesWe have never used the tool. Since we dont use PHP for our development needs (this forum is a 3rd party tool), we really cant comment on it. As of SQLyog having a similar feature – ummmmm – I dont think we will ever have it.
MemberQuote:believe you promised a Connection Management FeatureYes I did but this option is lower down in the TO-DO list. We first plan to make SQLyog compatible with SP & Views. Improved user management and unicode support are next in line.
MemberQuote:Problem is that you can have connections open to different MySQL-versions with different keyword-lists.Can SQLyog handle this ?
Nope. We will be having the same keyword list for all MySQL versions.
MemberWe have not yet updated SQLyog with the complete keyword list of MySQL v4.1. We plan to update it in SQLyog v4.1.
MemberIf the data is not confidential then can you mail me the exported .SQL file?
MemberOnly one image did the trick. I was just looking for a 35MB image so that my developers could work on it.
MemberThe issue is due to the fact that we add the whole query (in this case around 35M:cool: to the history window too. Thus the memory is not being released even after you have ceased using Insert/Update window.
Starting from v4.07 RC2, SQLyog will only log queries less than 4K.
-
AuthorPosts
