Please note: If this FAQ s empty you must choose English language from the drop-down-box below. Only English content is available as of now!
Navigation
- FAQ Home
- All categories
- About Webyog support and about this FAQ
- About the SQLyog program

- Connection issues

- Using the GUI
- Managing your MySQL Database Systems
- Database Schema Synchronization
- MySQL DATA synchronization
- Notification Services
- Importing external data
- Backup/Restore
- SQLyog Job Agent (SJA)

- Working with Views, Stored Procedures and Triggers
- Character Set and Localization Issues
- MySQL bugs that affect SQLyog
- Questions on Open Source and Compiling
- Instant Response
- Sitemap
Most popular FAQs 
- I get error 1130 "Host is not allowed to ... (115368 views)
- Error no. 2003: Can't connect... (52084 views)
- Error no. 1251: "Client does not support authentication..." (48088 views)
- Error no. 1045: "Connection denied..." (41330 views)
- SQLyog Version History (39943 views)
- What is HTTP-tunneling? (29283 views)
- Error No. 2005: Unknown MySQL server host... (28336 views)
- What Is SSH and SSH-tunneling? (25486 views)
- Why are Stored Procedures not created when I import ... (23452 views)
- Do I need PHP to use SQLyog with MySQL? ... (21514 views)
Latest FAQs 
- SQLyog Version History (2010-03-09 03:20)
- SQLyog is a client for the MySQL server - ... (2009-09-11 07:48)
- Can I use SQLyog with the various SQL-modes available ... (2009-08-20 08:02)
- Failed dependency for libstdc++.so.5 error (2009-08-13 11:22)
- Wrong results are returned for FOUND_ROWS(). (2009-08-12 06:31)
Managing your MySQL Database Systems » Data Types and Storage Engines
Problems with TIMESTAMP NOT NULL and MySQL 4.1
If you experience problems when using MySQL 4.1 with TIMESTAMP columns declared NOT NULL the reason is simply that SHOW FULL FIELDS returns wrong information for such datatype on this MySQL server version. Just try yourself this:
CREATE TABLE ´ts1´ (
´id´ int(11) NOT NULL AUTO_INCREMENT,
´ts´ timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (´id´)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE ´ts2´ (
´id´ int(11) NOT NULL AUTO_INCREMENT,
´ts´ timestamp NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (´id´)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
.. and you will see that SHOW FULL FIELDS returns the same for both - the 'NULL' column returns "YES" in both cases. This affects SQLyog in two different ways:
1) ALTER TABLE will show the NOT NULL checkbox for the column unchecked in both cases.
2) (more serious): Schema Sync will *think* that the TIMESTAMP column is defined NULL and not NOT NULL. When such table is the <source>, the <target> will be CREATED as NULL (or ALTERED to NULL if it exists on <target> as NOT NULL) .
As MySQL 4.1 is now out of active support we have decided that we will not apply any 'workaround' for this in our code, because all still-supported server versions including MySQL 5.0 are not affected by this server bug.
However notice that in SQLyog 8.05 we worked around a similar server bug affecting both 4.1 and 5.0 servers: On those servers SHOW FULL FIELDS will not expose an ON UPDATE CURRENT_TIMESTAMP clause for a TIMESTAMP column, what would cause similar problems with Schema Sync when syncing a TIMESTAMP ON UPDATE CURRENT_TIMESTAMP from 4.1/5.0 to 5.1/6.x servers. Here we will get information from SHOW CREATE TABLE and an ON UPDATE clause for a TIMESTAMP column will be synced correctly on all server versions where this clause applies (4.1 and higher).
Tags: -
Related entries:
- Do I need PHP to use SQLyog with MySQL?
- SQLyog gives you the most options for connecting to MySQL
- Welcome to the Webyog FAQ
- SQLyog Version History
- What is and what is not imported by the SQLyog Import External Data Tool?
Last update: 2009-04-04 15:11
Author: Peter Laursen
Revision: 1.0
You can comment this FAQ