MySQL Query Works on My Laptop, but Not on Server - php

I worked on a site locally through my Laptop. I have a table named blog and it has the fields post_id, title, markdown, author, added, and modified.
The fields Added and Modified are both DATETIME's.
When a user makes a blog post, PHP runs this query successfully: INSERT INTO blog (title, author, markdown, added) VALUES ('BLA', 'BLA', 'BLA', NOW())
I've gone into phpMyAdmin and ran the exact same query with working results.
Now, I exported my exact database into the server today and I noticed that no posts were being stored in the DB, so I tried running it through phpMyAdmin's SQL and it gave me the error Field 'modified' doesn't have a default value.
Why would this be happening? In my database, the default for both is None so I'm quite confused on what could be causing this.
My Laptop has PHP 5.3.1 and MySQL 5.1.41 (I installed XAMPP.)
The Server has PHP 5.3.5 and MySQL 5.5.8 (Out of desperation I installed the newest versions. The server was originally running MySQL 5.1 and a lower version of PHP.)
This has been killing me, hopefully someone knows what's wrong with this or how to fix it.
Edit: Here are the SHOW CREATE TABLE blog results.
Laptop:
| blog | CREATE TABLE `blog` (
`post_id` mediumint(9) NOT NULL AUTO_INCREMENT,
`title` varchar(160) NOT NULL,
`author` varchar(100) NOT NULL,
`markdown` longtext NOT NULL,
`added` datetime NOT NULL,
`modified` datetime NOT NULL,
PRIMARY KEY (`post_id`)
) ENGINE=MyISAM AUTO_INCREMENT=7 DEFAULT CHARSET=latin1 |
Server:
| blog | CREATE TABLE `blog` (
`post_id` mediumint(9) NOT NULL AUTO_INCREMENT,
`title` varchar(160) NOT NULL,
`author` varchar(100) NOT NULL,
`markdown` longtext NOT NULL,
`added` datetime NOT NULL,
`modified` datetime NOT NULL,
PRIMARY KEY (`post_id`)
) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=latin1 |
Auto Increments are different because of my tests.

ALTER TABLE blog CHANGE modified modified TIMESTAMP DEFAULT CURRENT_TIMESTAMP;
Or, more rarely, you might have a buggy version of MySQL on your server.
*I might have the syntax imperfect, I referred to the last comment on ALTER TABLE at the bottom of the manual page.

First: are you sure the data on your laptop exactly the same as the data on the server? Maybe you're not getting this error on your laptop because the default values are set on your laptop table somehow and not the server -- possibly an issue with how you exported the data.
When you say, the default is "None" do you mean NULL or do you mean literally the word "None"?
If both fields are datetime fields, then set the default to NOW() or, if you prefer to not have an actual date and time by default, use a string like "0000-00-00 00:00:00", or the JDBC friendly "0001-01-01 00:00:00".
Compare the structure of each table with the following command in a mysqlclient:
SHOW CREATE TABLE blog;

Dump the DDL from both versions using
$ mysqldump --no-data dabasename
and compare them (and check the man page for mysqldump(1) as I'm flying by memory here.)
Make sure you're using the same exact table description and that both versions are using the same engine.

Related

How do i fix this problem ive tried alot?

I run into an SQL query error.
The query:
CREATE TABLE IF NOT EXISTS `shoutbox` (
`id` int(255) NOT NULL AUTO_INCREMENT,
`user` varchar(255) NOT NULL,
`msg` varchar(255) NOT NULL,
`time` datetime(6) DEFAULT NOT NULL CURRENT_TIMESTAMP(6),
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
MySQL said:
#1064 - You have an error in your SQL syntax;
check the manual that corresponds to your MySQL
server version for the right syntax to use near
'(6) DEFAULT NOT NULL CURRENT_TIMESTAMP(6),
PRIMARY KEY (`id`)
) ENGINE=MyISAM ' at line 5
Since this looks like your first import.
MySQL reference manuals are per the link. As you can see 5.5 is so old its in a PDF version only.
Since you are importing a sql file, look closer at the text of it, it will say what version it came from. The first step should be to install the same major version of mysql (the first two digits like 5.7 or 8.0). If the last digit is later than the origin sql that's fine.
Don't start with 5.5, its too old. Consider a minimum of 5.7 first or 8.0 if the version of the sql dump is later.
Default keyword should be before the default value
`time` datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
assuming the posted code has been transcribed accurately this amendment fixes the posted error...
AND what's the point of not null AND a default?

Mysql 5.7 Innodb Delete query very slow randomly

I have table with 5 simple fields. Total rows in table is cca 250.
When I use PHPmyAdmin with one DELETE query it is processed in 0.05 sec. (always).
Problem is that my PHP application (PDO connection) processing same query between other queries and this query is extremely slow (cca 10 sec.). And another SELECT query on table with 5 rows too (cca 1 sec.). It happened only sometimes!
Other queries (cca 100) are always OK with normal time response.
What problem should be or how to find what is the problem?
Table:
CREATE TABLE `list_ip` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`type` CHAR(20) NOT NULL DEFAULT '',
`address` CHAR(50) NOT NULL DEFAULT '',
`description` VARCHAR(50) NOT NULL DEFAULT '',
`datetime` DATETIME NOT NULL DEFAULT '1000-01-01 00:00:00',
PRIMARY KEY (`id`),
INDEX `address` (`address`),
INDEX `type` (`type`),
INDEX `datetime` (`datetime`) ) COLLATE='utf8_general_ci' ENGINE=InnoDB;
Query:
DELETE FROM list_ip WHERE address='1.2.3.4' AND type='INT' AND datetime<='2017-12-06 08:04:30';
As I said before table has only 250 rows. Size of table is 96Kib.
I tested also with empty table and its slow too.
Wrap your query in EXPLAIN and see if it's running a sequential select, not using indexes. EXPLAIN would be my first stop in determining if I have a data model problem (bad / missing indexes would be one model issue).
About EXPLAIN: https://dev.mysql.com/doc/refman/5.7/en/explain.html
Another tool I'd recommend is running 'mytop' and looking at the server activity/load during those times when it's bogging down. http://jeremy.zawodny.com/mysql/mytop/
There was some network problem. I uninstalled docker app with some network peripherals and looks much beter.

MySQL: #1293 - Incorrect table definition

Designed Database and Table in Local Server Using MySQL 5.6.17 and Export into *.sql file.
When try to Import *.sql file into Live Server(MySQL 5.1.36) got below Error:
#1293 - Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause
Understood the issue through this link
Is there any way to import Local Server's *.sql file to Live Server without Updating MySQL Version?
TABLE:
CREATE TABLE 'currency' (
'id' int(11) NOT NULL AUTO_INCREMENT,
'currency_name' varchar(30) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT
NULL,
'country' varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
'currency' varchar(5) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
'created_by' int(11) NOT NULL,
'created_on' timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
'status' int(1) NOT NULL DEFAULT '1',
'modified_by' int(11) DEFAULT NULL,
'modified_on' timestamp NOT NULL ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY ('id')) ENGINE=InnoDB AUTO_INCREMENT=22 DEFAULT CHARSET=utf8;
NOTE:- Windows Server Running WAMP(Local Server) and QNAP(Live Server).
There is not a direct way to do it, since this is not a valid table definition for any version prior to MySQL Server 5.6.5.
You could edit the dump file by hand or with a tool like sed or perl to modify the offending lines, or you could change the table definition on the source server... but then your application, which presumably expects this behavior, isn't going to work properly.
You could also modify the table definition to make it valid for 5.1, with only one automatic timestamp, and use triggers to get the rest of the desired behavior.
The best course, of course, is one of these:
update the 5.1 server to 5.5 and then to 5.6, or
when developing for a 5.1 server, always use 5.1 in the development environment, so you don't get into conditions like this, relying on newer features that aren't compatible with older deployments... remembering, though, that there are some pretty significant improvements that happened in version 5.6.

PHP stops responding

I have a small(100-ish rows, 5 columns) table which is displayed in full for a control panel feature. When using IntelliJ to test development, it responds to the initial request, but never completes executing, and thus never serves any content. If I deploy the PHP files to my local web server, it serves the same content with no hesitation at all. Sometimes, when I load parts of the control panel that use no database access, it loads it just fine(albeit slow). I've upped the max memory allowed for requests in my cli/php.ini, and also increased the memory available to IntelliJ. My idea64.vmoptions is as follows:
-Xms128m
-Xmx3G
-XX:MaxPermSize=750m
-XX:ReservedCodeCacheSize=200m
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djsse.enableSNIExtension=false
-XX:+UseCodeCacheFlushing
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-Dawt.useSystemAAFontSettings=lcd
If I dump the table, it loads the page again, so I assume the problem is related to how much memory IntelliJ allows php to use, but I'm quite stumped as to what to look for. The only special thing about the table, as far as I know, is that it uses a very large primary key column. Table structure is as follows:
CREATE TABLE IF NOT EXISTS `links` (
`url` VARCHAR(767) NOT NULL,
`link_group` INT(10) UNSIGNED NOT NULL,
`isActive` TINYINT(1) NOT NULL DEFAULT '1',
`hammer` TINYINT(1) NOT NULL DEFAULT '0',
PRIMARY KEY (`url`),
KEY `group` (`link_group`)
)
ENGINE =InnoDB
DEFAULT CHARSET =utf8mb4,
ROW_FORMAT = COMPRESSED;
The row format is compressed to allow for said large primary keys. How should I proceed to if not solve it, find the cause?
I tried following Peter's suggestions, to no avail. I'm beginning to think this may just be IntelliJ not properly being able to serve PHP in my case. New table structure is as follows:
CREATE TABLE IF NOT EXISTS `links` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`url` varchar(767) NOT NULL,
`link_group` int(10) unsigned NOT NULL,
`isActive` tinyint(1) NOT NULL DEFAULT '1',
`hammer` tinyint(1) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY `url` (`url`),
KEY `group` (`link_group`),
FULLTEXT KEY `url_2` (`url`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=COMPRESSED AUTO_INCREMENT=1 ;
Just to be clear, the MySQL performance doesn't seem bad. SELECT * FROM links executes in 0.0005 seconds.
You might want to recreate that table. Your table definition might be causing the unpredicatable behaviour.
Try using the TEXT data type for the url field. Also, using that as a PRIMARY key is not funny. Use an id field for the primary key and then, add a unique index to the url field (if so desired).

PHP/SQL Date Created vs Date Modified

I am working on a function that compares the date created and date modified of images and return the status of each case with PHP + MySQL. However, I realized that the data i'm trying to compare both end up using the CURRENT_TIMESTAMP in MySQL so whenever they are updated they end up having the same dates.
Is there a way to just only save the first date the data is inserted into the database (date created) so it doesn't change based on date modified?
Any help is appreciated, thanks in advance!
UPDATE:
my timestamp columns are configured using "DEFAULT CURRENT_TIMESTAMP" not the "ON UPDATE CURRENT_TIMESTAMP" option. Any other work arounds?
UPDATE2:
Please see below for my table definition.
CREATE TABLE IF NOT EXISTS `images` (
`id` varchar(50) NOT NULL,
`patientid` varchar(8) NOT NULL,
`caseid` varchar(25) NOT NULL,
`image_name` varchar(256) NOT NULL,
`status` int(1) unsigned NOT NULL,
`comments` varchar(4000) DEFAULT NULL,
`mod_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Seems like your timestamp columns are configured with "ON UPDATE CURRENT_TIMESTAMP" option, which automatically updates them.
As there does not seem a way to change this on a column, you have to create a new column without that option.
See the TIMESTAMP manual for details visit timestamp-initialization

Categories