This is my query:
INSERT INTO tabla (campo1,campo2,campo3) VALUES ('$campo1','$campo2','$campo3')
Since 'tabla' has many more columns and some of them are not null and neither have a default value, I'm getting the mysql message: "Fiel 'column4' doesn't have a default value".
I'm running that on my local server, tried it out at online server and it does insert the row with no issues.
Does anyone knows if this has to do with some sort of configuration of the mysql.ini file or something like that? There are too many columns like that on my db, so changing columns to 'null' or set them a default value would take a lot of time. I think it could be fixed as it works perfect on the server.
Thanks.
UPDATE:
It is the SQL mode. I queried SELECT ##GLOBAL.sql_mode;
My local server returned: STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
The remote server returned an empty row.
Where can I change that setting on my localhost?
If you are sure that you are using the same schema both locally and on the remote server, it's probably the SQL mode of the remote server that's set different than the local SQL mode, you can check it with one of those:
SELECT ##GLOBAL.sql_mode;
SELECT ##SESSION.sql_mode;
This will reproduce the problem:
CREATE TABLE tabla (
campo1 VARCHAR(255) NOT NULL,
campo2 VARCHAR(255) NOT NULL,
campo3 VARCHAR(255) NOT NULL,
campo4 VARCHAR(255) NOT NULL);
SET ##SESSION.sql_mode= 'STRICT_TRANS_TABLES';
INSERT INTO table (campo1, campo2, campo3) VALUES ('a', 'b', 'c');
and this will work, even if there's a column costraint on campo4:
CREATE TABLE tabla (
campo1 VARCHAR(255) NOT NULL,
campo2 VARCHAR(255) NOT NULL,
campo3 VARCHAR(255) NOT NULL,
campo4 VARCHAR(255) NOT NULL);
SET ##SESSION.sql_mode= '';
INSERT INTO table (campo1, campo2, campo3) VALUES ('a', 'b', 'c');
Please see fiddle here.
Have a look at the manual at the Server SQL Modes page.
This weird behavior might depend on "sql_mode" system variable - it controls vast amount of quirks and settings.
So, check the mode by running select ##sql_mode; command on your both servers - it must output different values, so you know what mode is used on your local server.
If the column is not null you must provide its value when inserting record. There is no other way - it is not null just for forcing ANY data in it (even if its just EMPTY string. But you must provide it in the insert query.
You may add default value for the column.
Try importing remote table to your local one - that will minimize future problems with schema.
Related
Mysql :5.7
General Log: 1
log_output : Table
I have written some code using java to store images in a blob column of a table (tbl_attachment_mst).
My General Log settings are turned on and is configured to write to 'table'.
Whenever i add an image to tbl_attachment_mst , mysql does log it in the mysql.general_log table with _binary('some unreadable characters not sure what this is').
I have accidently lost contents of the table tbl_attachment_mst . Is it possible to recover my data from the mysql.generaL_log table??
I think i am having some issue with the character set while trying to execute the query that is stored in mysql.general_log.
(From comment)
CREATE TABLE tbl_attachment_mst (
attachment_id int(11) NOT NULL AUTO_INCREMENT,
file_name varchar(200) DEFAULT NULL,
created_date datetime DEFAULT NULL,
activate_flag tinyint(4) DEFAULT NULL,
file_id int(11) DEFAULT NULL,
type varchar(300) DEFAULT NULL,
attachment_asblob longblob,
PRIMARY KEY (attachment_id)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
insert into tbl_attachment_mst values
(default,'test.jpg',sysdate(),1,1,'Type',
_binary('some characters here'))
Grab it fast. I suspect the general_log, as a table, gets flushed in some fashion pretty fast.
It works just like a table, so SELECTs work. However, your SELECTs go into the general log unless you have turned it off.
Recommend doing SELECT ... HEX(col) ... to avoid the unprintable characters.
Please provide more details so I can try to simulate it and see what would work best.
SHOW CREATE TABLE
An approximation of the INSERT statement (or whatever was involved)
And if the grabbed hex is useful, you can use something like this to reverse the steps:
INSERT ... VALUES (... UNHEX(hex_string) ... )
using the below set of queries, i was able to get the exact data that was inserted into the db at that particular time.....
SELECT argument INTO #sql FROM mysql.general_log limit 1;
PREPARE sql_query FROM #sql;
EXECUTE sql_query;
These queries would insert the data back into the tbl_attachment_mst...
I'm using the MySQL Workbench 6.0 tool to migrating data from a MS SQL Server 2000 database to a MySQL 5.6 database and many of the create table constructs are giving the error "Default value N'no' is not supported" on columns that allow null, but define a default value. Here is some example code where the complaint is on the definition of the distribution column definition.
The Table construct looks like this:
CREATE TABLE IF NOT EXISTS `dbo`.`_tbl_access` (
`distribution` VARCHAR(3) NULL DEFAULT 'no',
`email` VARCHAR(100) NULL)
The idea is that you can store NULL, but have the default be 'no'. Is this a known problem to allow NULL, but to store a value of 'no' as default?
As stated in the MySLQ 5.6 documentation, you can't use your own default value on a column which can take NULL as a value:
If the column can take NULL as a value, the column is defined with an explicit DEFAULT NULL clause.
11.5. Data Type Default Values
If you want exactly the same behavior, you can use custom triggers. You may also consider redesigning the database, e.g. to ask yourself if a record should exist in the '_tbl_access' table if the answer for the 'distribution' field is undefined (NULL).
I have created a database table like this:
CREATE TABLE test(
name VARCHAR(30) NOT NULL,
password VARCHAR(40) NOT NULL);
I then added to it like this, which failed as expected.
INSERT INTO test(name, password) VALUES ('test', NULL);
But then when I tried this it inserted without a problem:
INSERT INTO test(name) VALUES ('test');
I tried to create the table differently but it didn't create:
CREATE TABLE test(
name VARCHAR(30) NOT NULL,
password VARCHAR(40) NOT NULL DEFAULT NULL );
So is there a way to get that to create an error when inserting?
Perhaps associated I think I will need to do something else to be able to validate data input into the database anyway and I think I saw something about constraints but I don't think these are supported in mysql? So is the null check and validation something I can't do the database with mysql?
By default, MySQL replaces implicit NULL values with zeroes (or empty strings for string datatypes).
You can work around this by enabling strict mode for your session or server:
SET sql_mode='STRICT_ALL_TABLES'
or add
sql_mode='STRICT_ALL_TABLES'
under [mysqld] in your my.cnf.
How to make sure that field is mandatory ? Here is what I mean
I have the following mysql table structure:
CREATE TABLE `new` (
`id` int(11) DEFAULT NULL,
`name` int(11) DEFAULT NULL,
`phone` int(11) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
Here is query with no data for phone
insert into new values(1, 'm', '');
But the query runs fine. What should be done so that mysql returns an error if there is no data for phone field? I can do that validation by php, but I'm curious how to do that in mysql.
Possibly setting the default value of the 'phone' column to NULL would make it fail insertion because it would end up null if you did not specify it.
Otherwise you're going to need to omit the phone column for the default to kick in, say in php you'd use empty($phone) ? null : $phone; or something along those lines.
INSERT INTO new VALUES(1,'m',NULL)
will cause error.
If you want to check whether is the phone number field is a blank string,
you can use a trigger in MySQL.
I haven't tested this, but I have a feeling the '' != null. What happens if you run
insert into new(id, name) values (1, 'test');
I bet you get an insert error...
Anyway, I think its probably better to be validating in PHP than waiting till you get to the database... inserts are expensive...
'' as the 3rd option doesnt make the value of phone null.. It is just equal to a blank string thats all.
if you want to see an error, replace '' with NULL.
I currently trying to use an Object Relational Mapper for CodeIgniter and I'm experiencing something I did not expect.
I have a table with a couple of fields, some of which are NOT NULL. An insert query is which is missing of the NOT NULL fields is generated -- a new row is added but with blanks for those fields.
I did not know MySQL would disregard the NOT NULL fields that aren't present in the query and insert the row anyways. Is there a way to restrict this?
-Edit-
Let me add a few more details and try to explain it a bit more
Here is a sample table:
CREATE TABLE `test` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`color` varchar(40) COLLATE utf8_bin DEFAULT '',
`shape` varchar(40) COLLATE utf8_bin NOT NULL,
`size` varchar(40) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COLLATE=utf8_bin
Here is a sample query:
INSERT INTO `test` (`shape`) VALUES ('foo')
I don't have size in my query yet it still adds the row - is this expected?
(The sample query was run in phpMyAdmin)
I believe the accepted answer is incorrect, given the question's test INSERT statement. It looks to me like MySQL's "strict mode" is turned off for this table or database. From the docs:
Strict mode controls how MySQL handles input values that are invalid or missing... A value is missing when a new row to be inserted does not contain a value for a non-NULL column that has no explicit DEFAULT clause in its definition...
If you are not using strict mode (that is, neither STRICT_TRANS_TABLES nor STRICT_ALL_TABLES is enabled), MySQL inserts adjusted values for invalid or missing values and produces warnings.
You can find out how your database is running with these queries:
SELECT ##global.sql_mode;
SELECT ##session.sql_mode;
Changing these values is discussed here: https://stackoverflow.com/a/5273824/27846
Empty string is not the same thing as NULL. Perhaps ORM inserts just '' for those fields.
Not a codeigniter dev, but I would hazard a guess that the issue is your ORM is passing blank values on to the database, I would check your logs to verify this and if its the case, check your ORM if it has some validation options.