[peterlaursen]

Sorry for not replying here in the first place.

and yes – we did change a little in beta 8:

Please refer to: http://www.webyog.com/faq/28_70_en.html

Quote:

The two situations where (TINY/MEDIUM/LONG) TEXTs and BLOBS are included in the WHERE-condition are

* TEXT/BLOBs that are primary keys

* WHEN there is a single column in a table only and this is TEXT/BLOB

[peterlaursen]

Just a clarification.

Licensingf is pr. computer with the extension that “individuals purchasing a single license may install a copy on a stationary computer and a laptop as well provided that this individual is the only user of the program and the two installed versions are not in use simutaneously.”

http://webyog.com/faq/30_38_en.html

And one more point. We did not release beta9 with another debugger on Friday as we forund a few more tools to test with.

[peterlaursen]

As far as Query Browser is concerned I just asked because I was not sure about it myself.

If it should not be possible for a client/connection to specify its own SQL_mode why did MySQL then introduce that from 4.1 to 5.0?

As said we have plans for the future to respect the global sql_mode to the most possible extend. But This is not priority at the moment. It will not be before next year that we looke detailed into it.

[peterlaursen]

User will need CREATE_TMP_TABLE privilege. This privilege was introduced with MySQL 4.02. SQLyog 5.2 (in beta) can handle ALL privileges for every MySQL version (including 5.1).

[peterlaursen]

Please read this FAQ:

http://webyog.com/faq/24_121_en.html

the problem is the a backup takes time. So if the database is open for writing while backup is done it is impossible to tell if if data are backed up as they were when backup job started or ended. For some systems this can be critical. For a Forum I do not think it will be important!

This is basically a problem of crating a 'consistent snapshot'. Recommended settings depend on the storage engine (MyISAM/InnoD:cool:. What do you use?

[peterlaursen]

when you click the title bar to sort data is affects only how data are displayed.

Actually SQL databases are not designed in a way so that 'raw order' matters. It also depends on the storage Engine (myISAM/InnoD:cool: whether 'unused space' are filled with data or not.

Basically you are supposed to use and ORDER BY clause when generating a result set. You export and import and keep the order you could try

Code:

SELECT INTO OUTFILE …. ORDER BY…

that will generate a sorted SQL-file. But how the server stores the data when they are stored, SQLyog cannot control!

[peterlaursen]

We do support MySQL versions from 3.23.x and forward (not the early betas and RC's).

What is the EXACT MySQL version? This SQL:

Code:

select version():

.. will tell

[peterlaursen]

please:

* tell the SQLyog version

* tell what operation you are doing.

* also: can you reproduce the problem – still have the case?

* please also attacte the CREATE statement for the table to ensure that we test with EXACTLY the same datatypes as you have.

actually the MySQL parser is not very accurate always. So the actual error could be in the line before!

[peterlaursen]

Confirmed.

I am not able to tell if this can be solved

1) without implementation of UNICODE

2) with implementation of UNICODE

3) or not at all

We will need some time to discuss/research into what actually happens.

[peterlaursen]

@]TGKnight

I understand you have SQLyog installed on 5 systems. Right?

Does the same thing happen on every system?

[peterlaursen]

I do not agree with this “SQLyog is breaking the documented behaviour for MySQL”.

MySQL has made it possible for a client/connection to specify its own sql_mode. That is also 'documented behaviour'! Did you check what MySQL Administrator/Query Browser does?

[peterlaursen]

hmmm …

I think the solution could be ctrl-click and shift-click modifiers, so that you will only need to click the first and shift-click the last checkbox. This is a pending request too in more situations/places – also DATA and RESULT tab.

comments?

[peterlaursen]

Just for your info:

We finally reproduced this once ourselves. And got the dumpfile. Actually we have changed a little in between, so that we do not write a timestamp anymore. As it is only possible to execute very little code after the crash we took that away and spent the available/possible codelines for something more useful.

Expect info about a new build later today.

[peterlaursen]

As of now we do not provide that option. You will need to 'search and replace' in an editor.

[peterlaursen]

They are equally safe and equally efficient. Actually they use the same code. The backup 'powertols' has a few more options than the 'export' tool.

1: you can deselect utf8 encoding. needed if you backup from MySQL 4.1 or higher and need to import to MySQL 4.0 or lower

2: it can be scheduled

.. and probably some more I just do not remember right now.

Regarding the lock situation:

1) What is table TYPE/ENGINE (MyIsam or InnoD:cool: ?

2) Please attach a screendump of your settings in the export dialogue.

[Author]

Posts