[peterlaursen]

“one which records the date of the record creation and a second which updates every time the record is created”

Not possible!

http://dev.mysql.com/doc/refman/5.0/en/timestamp-4-1.html

Quote:

For one TIMESTAMP column in a table, you can assign the current timestamp as the default value and the auto-update value. It is possible to have the current timestamp be the default value for initializing the column, for the auto-update value, or both. It is not possible to have the current timestamp be the default value for one column and the auto-update value for another column.

Your application(s) must handle it by explicitly writing “now()” or “CURRENT_TIMESTAMP” to either of the columns when either INSERTING or UPDATING. SQLyog 5.1 support writing “now()” or “CURRENT_TIMESTAMP” from the grids:

http://www.webyog.com/faq/8_116_en.html

http://www.webyog.com/faq/8_99_en.html

(and BTW this behaviour will be optional in 5.17)

[peterlaursen]

To restore the backup

1) with SQLyog: tools .. import from SQL statements

2) From commandline you can “source” the file

Windows: open commanline client .. connect (“mysql -uuser -p”) and enter “source [path_to]file.sql” on first line

Linux et al: sourcing is all in one line: “./mysql -uuser -p < [path_to]file.sql" .. when the 'mysql' client program is executed from 'current folder'. The .sql file only contains standard SQL statements and can be executed by any client (capable of more statements 'in one shot') no matter on what platform the server runs. 3) “can I use this capability to restore the db on a different server” Yes – provided that MySQL versions are not 'too much different'. The problem is that 'create statements' vary a little. If you have a backup from a 'higher version' that you want to restore to a 'lower version' it can be necessary to edit the file a little in a texteditor. Also with the new features of MySQL version 5 there can be a few syntax issues that must be corrrected because of imcompatible changes in MySQL itself (an example: the DEFINER clause as described here: http://www.webyog.com/faq/35_123_en.html .

Remember to use a text editor and not a word processor if you want/need to edit a backup file (and do it on a copy, of course)

The other issues that you shall be aware of are in particular:

1) the encoding. UTF8 is only supported from MySQL 4.1, so do not use it if you want to import to a lower version.

2) the max-allowed-packet size in MySQL configuration, possible PHP restrictions (with HTTP tunnel) and other network resource issues, read this: http://www.webyog.com/faq/24_101_en.html

3) appropriate selection of 'use' and 'drop' statements. As a general rule: use 'use', drop tables but do not drop the database.

I think you should start practising this a little before you need it seriously! Create a database with a few tables with a few rows of data in each, try the various settings, open the file in a texteditor, read it and understand it! Test your understanding of it by improting to an empty database. Do you get what you expected? Actually it is only around 5 SQL commands for a typical backup file that does not have anything else than plain table data.

[peterlaursen]

Fixed in the development tree.

[peterlaursen]

This is not expected behaviour if:

* 1: you checked 'TRUNCATE …'

* 2: there is no 'that long data' outside the visible program window.

Please create a ticket here:

http://www.webyog.com/support/ttx.cgi

.. and attach a small dump that illustrates the problem (if you did not overlook * 2:)

[peterlaursen]

We would like to look into this by the beginning of next week!

Please post any addittional observation.

plain ISAM/Cobol files are not uninteresting to us!

[peterlaursen]

Do you use very long Column names?

Please attach

* a small structure+data dump of a single table

* and a screenshot

illustrating this.

As I wrote: the problem is where to store all that information! There are 4 options:

1) the sqlyog.ini -file. Not usable if there a lot of data!

2) a table in the MySQL database. Only usable on 'localhost' databases

3) windows registry. As we go for a cross-platform release >> no!

4) some kind of embedded database. (XML,MySQL embedded, SQLite). As we use SQLite allready for autocomplete, that would probably be the best. But this is not overnight!

[peterlaursen]

We have been discussing this now!

We want to release 5.16 ASAP – probably in the weekend.

We also plan a 5.17 release (a bug fix/service release) shortly after. This issue will be adressed in 5.17.

[peterlaursen]

You are right. the Font settings are not complete.

There is no font setting available for Comments in CREATE TABLE, ALTER TABLE and for the MESSAGES, HISTORY and OBJECTS TABs.

That will be fixed no later than version 5.2. We are looking into it right now to see if we can do something very soon.

[peterlaursen]

Quote:

Is there any plans to allow column widths to either stick to the widest entry of data (without the huge trailing gap) or even better to remember the widths chosen by the user?

From tools.. preferences there is the setting “Truncate Column Headers….” to make it 'stick to the widest entry of data' .

As far as 'remember the widths' the problem is where to store that information!

[peterlaursen]

Is it this issue:

http://www.webyog.com/whitepaper/Preparing_Access__Migration.pdf

[peterlaursen]

aha .. it looks like this system 'duclicates' the information for some reason.

Any chance that you could help us getting a hold of the ODBC-driver and other software we need to reproduce the problem?

I do not understand why nothing happens when you select not to abort on error.

[peterlaursen]

SQLyog 5.16 RC1 has been released:

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

can you confirm the fix?

[peterlaursen]

Whu can't I download this file. What I get cannot be unzipped!

Now take it easy! there is a reason …

What type of database are you importing from?

What happens if you select NOT to 'abort on error' Does everything import OK then?

[peterlaursen]

Migration Toolkit …

That could explain.

Do you import into an existing table?

Check your settings!

Click 'advanced' button .. DDL/DML option

You can attach a screenshot on that TAB …

[peterlaursen]

You will need to explain when and how you get this message!

Program version? What are you doing?

Note that column names are ALWAYS case-insensitive in MySQL (also on Linux) so you cannot have a 'magasin' and a MAGASIN' column. That is unlike table names! Just a guess ….

[Author]

Posts