[Ritesh]

Indeed.

Full configuration about the CHUNK behavior has already been implemented in BETA 3 development tree.

[Ritesh]

Case sensitivity will be properly handled along with column order in structure sync in BETA 4.

BETA 3 will have all the accented characters and the HTTP Tunneling issues fixed.

[Ritesh]

Brendon Kozlowski wrote on Mar 9 2006, 06:05 PM:

2.) Result pane's style error: The X (for close) is grayed out, which is fine since you can always use Ctrl+2 (or Edit -> Hide) although it would be nice to have this active rather than disabled just for the sake of usefulness (even though I prefer to use the keyboard). Either way, the minimize and maximize (I'm assuming) controls are not there, but there is a visual style for where they would be, showing a highlight on hover.

This is an expected behavior.

The X on the right hand side in the Result pane is grayed out as it does not allow you to close any tab. The X is not present to hide the result pane but to close a tab if required. When having multiple tabs, the X is not grayed out in the editor pane and you can use it to close the tabs.

HTH

[Ritesh]

Can you try once with a different PC?

[Ritesh]

peterlaursen wrote on Mar 7 2006, 06:26 AM:

@ritesh

But I think there is as issue with the keyboard shortcut ALT+. I thought it should select n'th editor tab, but it works on the RESULT/DATA/OBJECTS/HISTORY tabs instead. 'Help..keyboard shortcuts' says it means 'select n'th editor tab'

It is a bug. ALT+n will select tabs in the RESULTWINDOW and not in the editor window.

peterlaursen wrote on Mar 7 2006, 09:03 AM:

Confirmed!

When the multitabbed feature was released with SQLyog 5.0 there was some arrows you could use to scroll the SQL window horisontally. Looks like it has disappeared with 5.01 or 5.02. Or rather they have!

See attached screenshot of 5.0

I can't tell the reason for this. Some code commented out by accident. Or bitmaps not available to compiler. But undoubtedly this is an easy fix!

Bug confirmed. Will be fixed in v5.1 BETA 2.

[Ritesh]

BTW, did you mean by *auto-connect* to reconnect to your MySQL server if the connection fails due to server timeout?

This feature is already implemented in SQLyog.

[Ritesh]

😮 😮

[Ritesh]

peterlaursen wrote on Mar 5 2006, 07:27 PM:

@ritesh

I think you might have missed reading my last post post here because of Forums Software upgrade.

So I just put this reminder …

Code:

/*[23:50:24][0 ms]*/ select * from `phpmyfaq`.`faq_faqadminlog` order by id limit 0,100
/*[23:50:26][0 ms]*/ select * from `phpmyfaq`.`faq_faqadminlog`limit 100,100

either you must ORDER BY PK with each select or not at all. The two select above may fetch identical rows!

The ORDER BY clause must be the same for all SELECTs on the same table with getting CHUNKS.

I saw that and indeed looks like a bug. I will check upon it today.

[Ritesh]

peterlaursen wrote on Mar 4 2006, 02:54 PM:

@ ritesh: whose problem are you now talking about?

Lacylester's problems is the empty columns names. Simply. no base 64 thing.

I just wanted to be sure that there was no issue with a rare sql_mode too.

I'll repeat:

We have four issues:

1) SQLyog beta 1 generates empty column names with HTTP-tunnelling.  You toul me that was fixed in BETA2 tree.

2) SQLyougtunnel.php did not call the function doing the set_names

3) With recent PHP versions there is an problem when SQL is generated from the GRIDs.

4) The base64 issue that I shal not comment

Those four issues may occur individually or at the same same.  Hence the confusion. Do you agree?  Did you verify 3) on my server?

To me it seems like you are completely confused abot this!  Lets have BETA 2 ASAP so we can see what is left of it!

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

Indeed lazylesters issue is regarding the Base 64 encoding. Read: http://www.webyog.com/forums/index.php?showtopic=1930. He has this issue regarding INVALID WHERE CLAUSE too. This is a bug and has already been fixed in v5.1 BETA tree.

1.) Solved

2.) Solved

3.) Working on it.

4.) Working on it.

[Ritesh]

It is a bug. Will be fixed in v5.2 BETA 2 or BETA 3.

[Ritesh]

peterlaursen wrote on Mar 4 2006, 11:23 PM:

With the new CHUNKED feature of SQLyog 5.1 HISTORY shows queries like

Code:

USE `phpmyfaq`
/*[23:50:21][0 ms]*/ show create table `phpmyfaq`.`faq_faqadminlog`
/*[23:50:22][0 ms]*/ select count(*) from `phpmyfaq`.`faq_faqadminlog`
/*[23:50:23][0 ms]*/ show keys from `phpmyfaq`.`faq_faqadminlog`
/*[23:50:24][0 ms]*/ select * from `phpmyfaq`.`faq_faqadminlog` order by id limit 0,100
/*[23:50:26][0 ms]*/ select * from `phpmyfaq`.`faq_faqadminlog`limit 100,100
/*[23:50:28][0 ms]*/ select * from `phpmyfaq`.`faq_faqadminlog`limit 200,100
/*[23:50:30][0 ms]*/ select * from `phpmyfaq`.`faq_faqadminlog`limit 300,100
/*[23:50:31][0 ms]*/ select * from `phpmyfaq`.`faq_faqadminlog`limit 400,100
/*[23:50:33][0 ms]*/ select * from `phpmyfaq`.`faq_faqadminlog`limit 500,100
/*[23:50:34][0 ms]*/ select * from `phpmyfaq`.`faq_faqadminlog`limit 600,100
/*[23:50:36][0 ms]*/ select * from `phpmyfaq`.`faq_faqadminlog`limit 700,100

Why must only first SELECT be ORDERed BY id (PK)??

We do an ORDER by only on PK columns. This insures that we dont get the same row two times in the dump. limit 100,100 is not guaranteed to return you the same row everytime when done like select * from table limit 100,100.

Quote:

I think there is a risk that that you miss some rows and get others twice.

If PK is not an autoincrement but anything else that most certainly will happen!

Not with the order by clause.

Quote:

I also would like to comment on this CHUNCKed feature.  I think it was a very bad idea from the start.  Remove it or make it configurable! With EXPORT it does not make sense at all.  With import it could make some sense sometimes.

It indeed makes sense in Export. Chunk based export is only done in HTTP Tunneling and not in direct connection. Since HTTP Tunneling is stateless, we need to get the whole table data in one shot. This creates problem in shared environment where there is a limit on how much memory PHP should use. Loading a big table completely in the PHP environment will certainly result in error. Thus we get data in chunks of 1000 and write the dump.

Quote:

But basically I would like to get rid of it for myself!  It takes the controls out of my hands.  BTW: Is this the reason for the slow export? I believe it is!

As of now it looks like the reason of the slow export. I will work on it tomorrow.

Quote:

You are AGAIN trying to hard-code what only users can know: their server settings and the size of each row.  With some BLOBs even 100 rows per CHUNK may be far too much.  And you cannot know WHAT THEY WANT so you cannot code what other people want!  And basically a user might want to import to ANOTHER server so the BULK size of max-allowed-packet (as of now) in no good idea either.

We already have plans to make it configurable before v5.1 FINAL.

Quote:

You have been wasting your time with this, and should instead have implemented the configurable BULK size.  It is just a constant to be read from configuration.

Most professional programs that I know of have 10 times as many settings as SQLyog!  You shall not decide for me.  I want to decide for myself!  Please understand that NOW!  <_<

Agreed but we are slowly and slowly moving every option to Tools -> Preferences to make it 100% configurable.

Quote:

1)

What happens if job is aborted (by user or as a result of a HTTP-error) after issuing a LOCK TABLES … READ and before UNLOCK TABLES? Will that have effect on the database for other users?  Could be the reason why MySQL invented the LOCK_TABLE privilege.

The LOCK TABLE will automatically go off when the connection is dropped.

Quote:

2)

Is it safe to have more HTTP-connections using the same tunnelling file?  I had quite a lot of HTTP-errors when I tried!

EDIT: now I studied how it works with BULK enabled.  The CHUNK overrides the BULK!  Total confusion and mismatch in my humble opinion!

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

This is a BUG. I will ask my engg. to work on it.

[Ritesh]

peterlaursen wrote on Mar 4 2006, 03:13 PM:

deep silence!

I asked if there was any need that I test this on more different computers?

If you have verified there is no need – if not I might do!

added: well I did test on both my computers.  Problem is the same.  And it is the same on my personal ISP too. 

And I believe the new CHUNK feature with HTTP-connections is the reason.  With 100.000 rows in a table you will now issue 1.000 SELECTS.  Each of them must create a new connection SQLyog <> tunnelling script <> webserver <> MySQL.  Establishing conncetion 1.000 times is 1.000 times slower than doing it only once! And establishing this SQLyog-PHP-webserver-MySQL connection is what takes most of the time.  SQLyog client must sit idle and wait each time this is happening.  Network software, hardware and webserver is in control.  SQLyog is out-of-control and has to wait.

Try exporting a big table yourself with HTTP and watch HISTORY while job is running.  You will see that each time a connection is established several seconds pass. That is how slow the type of connection is established. Selecting 100 rows and 100.000 rows in one SELECT are both very fast.  It only depends on MySQL performance – nothing else once webserver <> MySQL connection is established.    Do as few queries as possible.  Do one SELECT only when it is possible – not 1.000 SELECTs.  This is particularly important with HTTP-connections.  Beta 5.1 multiplies the performance issue with HTTP-tunnel by iterating the 'weak link in the chain' multible times.  1.000 SELECTS and 4 seconds for connections to establish in average is more than one hour.  One hour idle time for SQLyog!  And not unrealistic at all!

BULKs are created at the client, and performance is not affected by the connection type at all.  CHUNKs are each generated with one query to the server and takes a new connection for each.  First/BULK is right. Second/CHUNK is wrong!

Changing the mysql_connect() method to mysql_pconnect() in tunnelling file does not make much difference.  What I believe indicates that it is not webserver <> MySQL connection that is a problem, but establishing connection over the Internet.  Also when running with a local server the difference is not that big.

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

I have not forgotten the issue. Its all in my TO-DO list.

I was working on the issue yesterday and even I think out that the new feature to break down data in chunks is the issue.

I will research on it more tomorrow and let you know the details.

[Ritesh]

I have added this feature for v5.3.

It will take us another 3-4 months for v5.3.

[Ritesh]

peterlaursen wrote on Mar 3 2006, 01:36 PM:

That was what I expected (would normally be so if not server is running in ANSI-mode).

So with you server there is no need to/idea in setting sql_mode = '' – becuase it is already.  So this is not what your are missing! 

You can do this to understand your issue: Simply try to insert a row using HTTP-tunnel.  Yo get the error message and nothin is inserted.  However the query is logged to HISTORY.  Look at it and you'll se that column names are empty strings.

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

I don't think his problem is related to sql_mode. For some reason the Base64 encoded data sent by SQLyog is getting changed before it reaches SQLyogTunnel.php for processing.

[Ritesh]

We never gave any thought on these things.

Maybe we should but after 5.2.

[Author]

Posts