Forum Replies Created
-
AuthorPosts
-
peterlaursenParticipant
unchecking “create bulk insert statements” will cause the server and the client to renegotiate the connection with each statement, I think. Probabaly that's why it is that slow! But with Sqlyog as of now it is the only way you can't decide the packet size.
peterlaursenParticipantthat shouldn't have been sent until it was finished!
continue;
….. are longer with Sqlyog then with command-line tool ??
peterlaursenParticipantoh that's it .. once more!
max_allowed_packet is a setting in your MySQL configuration file (my.ini(windows)/my.cnf(unix-Linux))
I think that after installation it is as low as 2M and that's not much. Try raising the value.
On my local server I'm using “max_allowed_packet = 100 M” and MySQL does not take significant resources anyway.
After editing the ini-file you must stop and restart the MySQL server for the changes to take effekt.
But also try from Sqlyog in the settings i the “export data” dialogue box to uncheck “create bulk insert statements” before generating the .sql
Both methods should work ….
Strange though that the error occurs with Sqlyog and not command-line tool.
But maybe the insert statement for the table i.e.
insert into `mybase`.`mytable`
(column1, column2, etc)
values
( x1,y1 ,z1; x2,y2,z2; etc)
peterlaursenParticipant>> surferjon2
If you have any proposals on HOW Stored Procedured and Triggers could be managed by Sqlyog then describe it and post it in the forums, or just send it to Ritesh. I sent him a proposoal on how to integrate VIEWs. Your are welcome to read it from her: http://www.deepeter.dk/view.doc.
I also proposed that (since they are defined with the data structure) SP's an Triggers be displayed in the Object Browser with the Database or table that they are defined with. Somewhat like http://www.deepeter.dk/browser.jpg. But what to DO with them ? Any ideas ?
peterlaursenParticipantThat's strange in my opinion. When using Sqlyog are you then logged on as ROOT too ?
And is the windows machine where Sqlyog runs the same machine where the Windows Mysql server runs too ?
Can you use the .sql-file created by sqlyog from MySQL command Line under Windows ?
You can also try restoring the .sql using “MySQL administrator” and see if the problem is the same.
two more things that might have something to do with it:
1) Character_set settings on the two servers. Does the “create table”-statement specify a character set and collation ? Any particular language setting on the two machines ?
2) has he Mysql Server(s) (now running 4.1.9 been) updated from earlier versions (4.0.x or earlier) , and it that case, did you remember to update the GRANT-tables ?
The MySQL-documentation
http://dev.mysql.com/doc/mysql/en/news-4-1-10.html writes in it's changelog for ver. 4.1.10
Quote:With lower_case_table_names set to 1, mysqldump on Windows could write the same table name in different lettercase for different SQL statements. Fixed so that consistent lettercase is used. (Bug #5185) HAVING that referred to RAND() or a user-defined function in the SELECT part through an alias could cause a crash or wrong value. (Bug #8216)although it is not exactly your problem it might be a related problem.
Is there a chance that you could update the win installation to 4.1.11 (latest release in the 4.1 -series) ? With the new installer it's only two minutes. Just don't run the configuration wizard not to overwrite your my.ini! And you could create a “Systems Restore Point” in Win XP to undo (I works that way!) . But there is quite a lot of bugs fixed from 4.1.9 to 4.1.11 (and more in 4.1.12 (not released yet)) so maybe that's worth a try ?
peterlaursenParticipantI thin djpate has a point …
If your company issued more regular “Press Releases” when something new happened with sqlyog then undoubtedly it would be much easier to find sqlyog on the internet.
peterlaursenParticipant1) port 3360 .. I guess you mean 3306 ??
2) version 1.4 .. I guess you mean 4.1 ??
Can you log on as ROOT ?
Maybe this is trivial to you (and maybe it is not) but MySQL does not use the Windows User Management.
It operates its own user accounts.
peterlaursenParticipantoh … it was there 🙂
peterlaursenParticipantI would prefer to let Ritesh answer your question 😀
BTW I think it's about time for him to wake up now – it must soon be working hours where he lives!
peterlaursenParticipantThere is a small bug too.
ALTERing tables with a TIMESTAMP field from sqlyog produces this code
alter table `test`.`tablename1` ,change `mytime` `mytime` timestamp DEFAULT 'CURRENT_TIMESTAMP' NOT NULL
should be
alter table `test`.`tablename1` ,change `mytime` `mytime` timestamp DEFAULT CURRENT_TIMESTAMP NOT NULL
String 'CURRENT_TIMESTAMP' is illegal as a timestamp!
peterlaursenParticipantI'm not sure..
But probably the KEY used for encrytion is different with different MySQL installations.
It's quite simple to test it if you have two servers. Make two identical user on each, SHOW the password and compare.
It would be bad security if Passwords were portable.
peterlaursenParticipantone comment to that …
with the INSERT and UPDATE statement it is only the FIRST timestamp field in the table that is effected.
Very often you'd like to have a timestamp showing record_create_time and another showing record_update_time.
If there is a change in data in some other colums and the UPDATE does not reference the first (and only that) timestamp field, then the first will be updated with current time.
Setting ALL timestamps defined with “NOT NULL” to NULL would update both and I don't like that!
But as much flexibility as possible without too much “fuzz” … 🙂
peterlaursenParticipantthere should be three methods:
Automatic updating of the first TIMESTAMP column in a table occurs under any of the following conditions:
1) You explicitly set the column to NULL.
2) The column is not specified explicitly in an INSERT or LOAD DATA INFILE statement.
3) The column is not specified explicitly in an UPDATE statement and some other column changes value. An UPDATE that sets a column to the value (allready has – I thik should have been there! – PL) it does not cause the TIMESTAMP column to be updated; if you set a column to its current value, MySQL ignores the update for efficiency.
from:
http://dev.mysql.com/doc/mysql/en/timestam…mp-pre-4-1.html
I just tested it and it works here! But standard behaviour of sqlyog is to keep the current value of the timestamp in the UPDATE statement. You can copy the sql from the history-pane and delete the timestamp field from the UPDATE statement.
I think we are missing an option here to let the user decide whether first timestamp field should be updated.
peterlaursenParticipantI believe Ritesh answered this question before, and as I remember the answer, it was like:
It was in previous versions. But with the latest C-api from MySQL it went away for some strange reason.
peterlaursenParticipantI am sorry .. something went wrong with my mouse
is it just
select * from `table1` where `num` in (select `num` from `table2` where `unit` = “50”);
that should be
select * from `table1` where `num` = (select `num` from `table2` where `unit` = “50”);
If the inner statement runs and returns a single value the latter should run.
But I can't see your data – so what it returns …. 🙄
-
AuthorPosts