[Ritesh]

@chrono: What does the query

Code:

show variables like '%character%'

return?

[Ritesh]

peterlaursen wrote on Mar 16 2006, 02:16 PM:

just a small observation:

HTML-export generates like:

Code:

01

Мужские

Note it does not use ISO 8859 '&aring' for 'е' but simply hex E5 (decimal 229) etc.

However Firefox is smart enough to realize that this must be cyrillic!

Even when there is no charset information in the header of the HTML-file

IE and Opera does not! Unless I force them to use windows-1251 encoding.

(@ritesh: shouldn't there be a charset=”windows-1251″ declaration in HTML-file when data are cp1251?).

I think a as-fast-as-possible implementation of UTF-8 is the only real solution to all these problems.

In another thread I linked to a few libraries!

Yes indeed. We have to specidy that in the HTML header. We will work on it once we fix the dump, write and the user issue with accented characters.

[Ritesh]

Thank you for your data.

We are working on it and we will revert back soon.

[Ritesh]

We have replaced all the LISTVIEW controls with our GRID control. GRID has never been reported to have the above painting issue. I hope GRID will solve it. BETA 3 should have this fix.

[Ritesh]

peterlaursen wrote on Mar 14 2006, 01:05 PM:

@ritesh – actually I have a question too. See the screenshot of my TAGS-folder. There are quite a lot of ZERO-size .db files with cryptical names. What are they? I think it is new with BETA2 – I don't remember this with BETA1.

Starting from BETA 2, we have changed the .db name from connectionname.db to a filename which is a checksum of the connection name + the connection details. This allows one to have any character in the connection name, multiple connections with the same name and couple of other usability issues.

.db with 0 size is strange. I am not able to reproduce it. Can you just delete the tags folder and connect/reinstall again?

peterlaursen wrote on Mar 14 2006, 01:50 PM:

this is stuff for Ritesh to study! But undoubtedly the is an issue with such amount of data to be cached by SQLyog after rebuild. If SQLite Browser opens the file, the file probably is OK ifself.

Two questions more:

1) does autocomplete work OK with that big .db-file? (if you start without rebuild?)

2) what happens if you start rebuild manually (from 'powertools' ?)

All the above crashes/crash on startup is due to a memory overflow bug which has been already fixed in BETA 3. Now no more crashes.

vygi wrote on Mar 14 2006, 03:42 PM:

1MB .db file with 8,519 rows table is big?

In this case, word “Enterprise” should be removed from the product name as SQLyog is not enterprise-ready!

This was just a bug and 5.1 is still in BETA. Starting with BETA 3, you can have a DB with 'n' number of tables with 'n' number of columns in each table.

[Ritesh]

By default, LOCK TABLE and all FLUSH options are unchecked in Scheduled Export Wizard.

LOCK TABLES FOR READ is checked by default in Export Database As SQL Statements option. It will be UNCHECKED (by deafult) starting from BETA 3.

[Ritesh]

This is a known bug which came to our notice only yesterday.

We have fixed it in BETA 3. Expect BETA 3 by tomorrow evening Indian time.

[Ritesh]

Nobody replied to Jan's actual problem. His problem is that if he has a FLOAT datatype as a PK or part of a composite PK, then SQLyog uses that column in the where clause. Now I had a talk with the MySQL developers on the same subject. There are many issues when you use FLOAT datatype in a where clause.

Quote:

Try issuing the following query on both the Linux and Windows machines.

SELECT FORMAT(id, 0) FROM tablename1;

In my testing on Windows I received the following:

mysql> SELECT format(id, 0) FROM tablename1;

+

---

+

| format(id, 0) |

+

---

+

| 9,999,100,476,915,712 |

+

---

+

This shows that number provided is not stored exactly when using FLOAT. How/what is stored depends upon both the Operating System and the CPU. More on this can be found in the documentation at http://dev.mysql.com/doc/mysql/en/problems-with-float.html

This is general problem with floating point types. They are:

1) Stored as approximate values

2) Platform dependent

This problem is covered in MySQL Manual at http://dev.mysql.com/doc/mysql/en/problems-with-float.html

Besides everything floating point types should be *never* used as a Primary Key not even as a part of composite PK.

This is why when SQLyog does a WHERE clause against a FLOAT datatype it fails. Since this issue has been taken up, here is another comment by a MySQL developer:

Quote:

Explain to your customers that using FLOAT such way is like shooting themselves in their left leg. If they really insist on doing that neither MySQL nor SQLyog can stop them, but we strongly recommend finding alternative solution.

Thus, changing the data type from FLOAT to DECIMAL works.

His update query works because 99.99%, he is not using the column in the WHERE clause when he is writing the UPDATE SQL query.

[Ritesh]

Fixed in BETA 3 development tree.

[Ritesh]

Works here.

[Ritesh]

Can you PM me the name and key that you are using? Actually, if you have v5.02 registered in your system, SQLyog 5.1 will not ask you for registration. It will automatically seek the last registration.

[Ritesh]

I think MySQL is case sensitive by default in Linux.

[Ritesh]

Where are you placing the cursor when you press F5? I think you are placing the cursor outside the query and thus SQLyog throws up the error.

It might be a bug with SQLyog too. Can you attach a screenshot with the cursor position?

[Ritesh]

peterlaursen wrote on Mar 10 2006, 03:49 AM:

But it does not work as you describe it here either. See attached. In this situation it should be possible to close the active RESULT tab. Right?

But X is 'greyed out'.

Nope. We don't allow any tab to be closed in the result pane. If you see the UI of FireFox, there is only one X for all the tabs. You click on it to close the currently selected tab. Since we don't allow closure of result pane tab, it is disabled.

peterlaursen wrote on Mar 10 2006, 05:55 AM:

BTW: I would prefer that the X was on the tab itself!

All the multi-tab environment tools use one common X for all the tabs. So we are just following the standard 🙂 Even VS 2005 has the same UI.

More images at: http://images.google.com/images?sourceid=n…tab&sa=N&tab=wi

[Ritesh]

We are working on this issue and will get back soon.

[Author]

Posts