[peterlaursen]

Just go on .. ideas are welcome. Actually I was not aware the Information_Schema keeps track of changed tables and the time of it. But that is right, it does.

We will not change anything here in the 5.2 tree, I think. But never say 'never' …

Quote:

It would be great to have the possibility to automaticly rebuild only the tag files of the active/selected database.

It is a possibility to define a single database with the connection.

Except that on some systems the tag-building gives some audible harddisk noise, are there then any other issues? Isn't the system responsive?

[peterlaursen]

ooooops!

The PLINK that was shipped with the 5.2 installer is the wrong version. It is the one we used before 5.15. A 'last moment mistake'. The PLINK that ships with 5.18 works with 5.2 too. You can copy it. Will be fixed in Beta2 of course (planned for the end of the week).

We cannot reproduce the HTTPS problem however! You write:

Quote:

I get “FATAL ERROR: Network ERROR: connection timeout”. In the end, I even copied the sqlyog.ini from 5.18 to 5.20, but still with no results. I also tried HTTPS tunnelling, but the same error occurs.

Do you seriously mean that you get “FATAL ERROR: Network ERROR: connection timeout” with HTTPS too?

[peterlaursen]

Quote:

What's going on, I wonder? ^^;;;

Well, I wonder too. There is absolutely no intentional difference between the two in this respect!

But I can confirm the issue with 5.2 and SSH-tunnelling (I have no option to test HTTPS at the moment).

So yes .. beta trouble. Every bit of code has been moved around and something went wrong it seems!

It is likely that it is a trival bug! Will be fixed of course.

HTTP-connection works OK here. Can you confirm this?

Thanks for beta-testing!

[peterlaursen]

Looks like same thing as here:

http://www.webyog.com/forums//index.php?sh…amp;#entry10966

This query:

select `TABLE_NAME` from `INFORMATION_SCHEMA`.`TABLES` where `TABLE_SCHEMA` = 'your database' and `TABLE_TYPE` = 'BASE TABLE'

is what SQLyog sends to 'fill out' the Object Browser with tables. I think it does not return anything either?

(replace 'BASE TABLE' with 'VIEW' and you have what is needed to show Views).

You should absolutely not need to read the Ex2fs/Ext3fs 'Lost+found' folder! This folder is used only by a file system utility (similar to 'checkdsk' on Windows) to recover files that have been lost.

I think you should tell the sysadmin the examples of queries that you should be able to get result from and te error messages that you get.

[peterlaursen]

Yes that was what I meant. It is effective 1O MB. A big One.

[peterlaursen]

the BULK setting is an internal SQLyog setting. It is not a MySQL server parameter.

the BULK specifies how long a generated INSERT statement will be allowed to be in the .SQL file.

You probably have some my.ini 'templates' (named like 'my.large', 'my.medium'. You can try to rename either of those to my.ini and see what difference it makes.

[peterlaursen]

We have a FAQ on CSV-import: http://www.webyog.com/faq/28_73_en.html.

In advance you must create a table with the columns 'Commune', 'Codepos', 'Departement' and 'INSEE' of appropirate type.

With these data it would be easiest to 'fill Excel-friendly values' and next edit these two:

'delimited by' is SEMICOLON (Continental European EXCEL CSV-format!)

'enclosed by' is LEFT EMPTY/UNCHECKED

'escaped by' most likely does not really matter here – let it be as \

'lines terminated by' is 'rn' (maybe you know it as – it is just another way of expressing the same thing!) if file is generated on Windows and only 'n' if generated on Linux/Unix.

AT THE BUTTOM you enter “1” so that the header line is not read as data, but skipped.

the only issue that I could foresee here is if you have a ';' (semicolon) in some of your data. That is what escaping is for then. But most likely you don't!

[peterlaursen]

thx for quoting me .. but you may say something too 😮

[peterlaursen]

Is the .SQL generated with SQLyog and if yes how is BULK settings?

http://www.webyog.com/faq/24_101_en.html

I would experiment a little with different BULKs on BOTH servers! Say 100 KB, 400 KB, 1 MB, 4 MB, 10 MB for instance. But the difference is impressive!

also: Do you have direct connection to both? Note that if one (the slow one) is connected with HTTP-tunnel, the HTTP-connection will need to be (re-)established for each statement- and that may take a few seconds every time. So if you have individual INSERT statement (one statement per row and a million rows then calculate yourself (3 seconds * 1.000.000) – where NOTHING AT ALL happens!

[peterlaursen]

what does this SQL returns

Quote:

select `TABLE_NAME` from `INFORMATION_SCHEMA`.`TABLES` where `TABLE_SCHEMA` = 'your database' and `TABLE_TYPE` = 'BASE TABLE'

this is the query that SQLyog sends in order to distinguish between VIEWS and TABLES ('show tables' don't). If you cannot get such data when querying Information_Schema something is wrong with the server!

[peterlaursen]

As you are an ENTERPRISE user you could use the backup 'powertool'. It will let you uncheck the UTF8 encoding that is not supported by MySQL 4.0. That will solve issues with non-ASCII characters. But you will have to edit the 'create table' syntax a little (deleting the SQL_MODE, ENGINE and DEFAULT CHARSET definitions).

“are you planning on incorporating this feature in a future release?”

Well. no plans actually. I think we not even discussed it. Maybe we should! And that would then also apply to 'copy to other host'.

However 'data sync' (when table structures are created in advance) should work across versions.

[peterlaursen]

hmmm…..

some kind of 'parametric favorite' … well, thinking about it! Absolutely worth considering!

But actually we do want to restore the old filtering option. And also add some more advanced GUI SQL-building functions.

What happened with 5.0 was that the internal storage of data was changed and the old code using for filtering did not work with the new storage format. And since then other issues have been considered more important.

[peterlaursen]

Simply try removing all the lines containing 'conditional comments'. SQLyog 'import from SQL-statements' have a problem with those. It is allready reported here: http://www.webyog.com/forums//index.php?showtopic=2299 – and is a SQLyog bug. 'Conditional comments' should not be stripped out by a client. The server should handle this!

There is no problem importing data from MySQL 4.1 to 5.0 without them.

You can also paste the DUMP into the SQLyog editor and 'execute all' (double green icon). Here is no problem with those comments!!

BTW: This looks to be a 'mysqldump' dump and not a phpMyAdmin dump?

[peterlaursen]

Fixed in 5.18!

[peterlaursen]

This was removed in version 5.0 (I think) as it was not compatible with other functions introduced at the time (and which were judged more important). We will introduce it – or something like it – again.

I also think that it is not described like that in the help file of recent versions (5.18 and 5.2)?

But it is true that there was a period after we removed the feature where the help file did not reflect that.

[Author]

Posts