Integrity constraint violation: 1048 Column 'temporary_address' cannot be null error in nullable field - mysql

I set the default value for a field on migration but it still gives an error when I left form field temporary_address empty
Is no-value and null is same in laravel? or something else.
my php version: 7.2.15
my mysql version: Ver 14.14 Distrib 5.7.25
My laravel version: 5.7.27

$client->temporary_address = $request->get('temporary_address');
please change this to
if(!empty($request->temporary_address)){
$client->temporary_address = $request->get('temporary_address');
}

i don't know why you decide to not using nullable() on the temporary address, while the other already using nullable
why you got an error ?
Because your temporary_address not accepting null value, and you set default value as an empty string, therefore you got an error like in your post, the solution change the default value to some value, not an empty string or easily make it nullable the best solution.
change this code
$table->string('temporary_address')->default("");
since you already run migration to update it, you need to write it down like this
$table->string('temporary_address')->nullable()->change();
therefore you can left your temporary address empty

Related

Incorrect string value - MySql

I have a problem with MySql.
My version of MYSql is : 5.7.33 - MySQL Community Server (GPL)
I have create a discord Bot in node.js, and i have a mistake when a new user with pseudo like this : legoshi🌌🌧
So i have try to follow this topic : How to fix "Incorrect string value" errors?
So i convert my Database in : utf8mb4_unicode_ci
And my error is still here.
At the begin my database was in utf8 and i have the error too.
code: 'ER_TRUNCATED_WRONG_VALUE_FOR_FIELD',
errno: 1366,
sqlMessage: "Incorrect string value: '\\xF0\\x9F\\x8C\\x8C\\xF0\\x9F...' for column 'user' at row 1",
sqlState: 'HY000',
index: 0,
sql: 'INSERT INTO registre (id, user, autohit, ultimate, platinium, `Date Inscription`) VALUES (210490816542670849, "legoshi🌌🌧", 0, 0, 0, CURRENT_TIMESTAMP())'
}
So i don't no how to change this. I have see a lot of topic and all seems to be fix with utf8mb4_unicode_ci but not in my case.
Thanks for you're help.
In MySQL, there are several places where you can set up a character set:
On the server level
On the database level
On the table level (for each table)
On the field level for all character-based fields
On your connection (telling the server what charset will be used in packets you send to the server)
Basically, server-level, database-level and table-level are just defaults for newly created items: New databases are generated with the server's default. New tables are created with the database's default, new fields are created with the table's default. However, only the field-level charset is what actually counts.
So first, you should make sure that the fields you want to store the data in actually are set up to utf8mb4_unicode_ci. Then, you need to connect to the server using exactly the same charset. Be aware that also the collation should match.
You can find out what character set is in use by issuing the following query:
SHOW VARIABLES LIKE 'character_set_%'
You'll see several variables indicating which default is set for various scopes. Have a look especially to the variables character_set_client and character_set_connection. If the connection does not have the correct character set specified, you need to set it up on connection.
It's a good practice to have all character sets match identically. Mixed values will sooner or later cause trouble.
To check the character set which is set up for the field, have it displayed with the command
SHOW CREATE TABLE registre

Cassandra: Cannot parse <col_Name> as hex bytes: MarshallException

I was trying my first 'Helloworld' application in Cassandra. Whenever I try to add any data to my keyspace column family I get this error:
[default#MyKeyspace] set User['ehewitt'] ['fname']='Eben';
org.apache.cassandra.serializers.MarshalException: cannot parse 'fname' as hex bytes
This is despite the fact that I have executed
[default#MyKeyspace] assume Users keys as utf8;
So the above command does not seem to have any effect at all. How do I solve this issue?
Cassandra is assuming the columns as bytes.
Check with
help assume;
assume User keys as ascii;
assume User comparator as ascii;
assume User validator as ascii;
assume User sub_comparator as ascii;
set User['ehewitt']['fname']='Eben';
Value inserted.
Elapsed time: 216 msec(s).
I had similar problem, but the cli told me that the value is what cannot be parsed.
set game_outcome['1']['userId']='123asdasd';
cannot parse '123asdasd' as hex bytes
so I tried to use utf8 function like this :
set game_outcome['1']['userId']=utf8('123asdasd');
cannot parse '123asdasd' as hex bytes
Try
set User['ehewitt'] [utf8('fname')]='Eben'
I tried to use set some assumption like this
assume validator keys as utf8;
validator not found in current keyspace.
But as you can see it did not work as well !
I hope this answer helps.
Starting the CLI
You can start the CLI using the bin/cassandra-cli script in your Cassandra installation (bin\cassandra-cli.bat on windows). If you are evaluating a local cassandra node then be sure that it has been correctly configured and successfully started before starting the CLI.
If successful you will see output similar to this:
Welcome to cassandra CLI.
Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit.
You must then specify a system to connect to:
connect localhost/9160;
Creating a Keyspace
We first create a keyspace to run our examples in.
create keyspace Twissandra;
Selecting the keyspace to user
We must then select our example keyspace as our new context before we can run any queries.
use Twissandra;
To Create A Column
We can then create a column to play with.
create column family User with comparator = UTF8Type;
For the later examples to work you must also update the schema using the following command. This will set the return type for the first and last name to make them human readable. It will also add and index for the age field so that you filter your gets using the Users name field.
update column family User with
column_metadata =
[
{column_name: first, validation_class: UTF8Type},
{column_name: last, validation_class: UTF8Type},
{column_name: age, validation_class: UTF8Type, index_type: KEYS}
];
To Add Data
To add data we want to into our new column we must first specify our default key type otherwise we would have to specify it for each key using the format [utf8('keyname')] this is probably advisable if you have mixed key types but makes simple cases harder to read.
So we run the command below, which will last the length of you cli session. On quitting and restarting we must run it again.
assume User keys as utf8;
and then we add our data.
set User['jsmith']['first'] = 'John';
set User['jsmith']['last'] = 'Smith';
set User['jsmith']['age'] = '38';
If you get the error like this cannot parse 'John' as hex bytes, then it likely you either haven't set your default key type or you haven't updated your schema as in the create column example.
To Update Data
If we need to update a value we simply set it again.
set User['jsmith']['first'] = 'Jack';
To Get Data
Now let's read back the jsmith row to see what it contains:
get User['jsmith'];
The get command uses API#get_slice
To Query Data
get User where age = '12';

How to get a warning when a FLOAT value is inserted into an INT column in MySQL?

I have acreated a Table containing a column of type INT:
CREATE TEMPORARY TABLE `myTab` (`int` INT, `text` TEXT, `float` FLOAT);
Now I try to add a float value into the INT column
INSERT INTO `myTab` (`int`) VALUES (13.34);
I don't get a warning:
SHOW WARNINGS;
Although the column contains only 13 afterwards:
SELECT * FROM `myTab`;
Is it somehow possible to get a warning when a float value is added to a integer column? I'm currently using mysql Ver 14.14 Distrib 5.5.31, for debian-linux-gnu (i686) using readline 6.2
Add: I'd like to avoid adding a "check for dots" for each INT-column (How do I check to see if a value is an integer in MySQL?). I'd prefer a warning when data is lost during casting to INT.
You could use a DECIMAL(n, 0) type instead of INT. Attempting to insert a non-integer number into such a column does raise a warning.
CREATE TEMPORARY TABLE t (id DECIMAL); -- equivalent to the default DECIMAL(10, 0), which covers the range of INT
INSERT INTO t VALUES (0.9); -- raises warning "1265 - Data truncated for column 'id' at row 1"
SELECT * FROM t; -- 0.9 was rounded to 1
I am aware this is only a workaround, and certainly has a negative impact on performance (albeit probably minor). But this is the only approaching solution I have been able to come up with.
EDIT: I have tested different scenarios to try an get a warning or a least an error for this but with no luck so i suspect that its either a intended behavior or its a mysql bug (although i didn't found a already known bug that describes this) so i think the best/only solution is the one posted by YaK
Use this:
TRADITIONAL
Make MySQL behave like a “traditional” SQL database system. A simple
description of this mode is “give an error instead of a warning” when
inserting an incorrect value into a column.
set global sql_mode="TRADITIONAL";
For more info read this.
UPDATE: what i purposed above is to get a error instead of a warning because with the warning the data is still inserted thus you will have corrupt data but if you still want to use warnings instead of errors then you have to use the default sql_mode:
set global sql_mode="";
EDIT: be sure that the warnings are enabled :
set global sql_warnings=1;
better yet you can add it in the config file my.cnf so that it will not be overwritten when mysql restarts .

How do you properly update a mysql field with NULL?

How does one properly update a mysql field with a NULL value when using a variable in the sql query?
I have a variable called $timestamp. When it's set to date( Y-m-d h:i:s ) I have to wrap it in quotes because I'm passing a string in my mysql query. When $timestamp is set to NULL, the database query contains '' as the value for $timestamp and the field updates to 0000-00-00 00:00:00. It's important to keep this field as NULL to show that the process has never been run before.
I don't want to use now() because then my sql statement is not in sync with my class variable $timestamp.
I don't want to set $timestamp to 'NULL' because then that variable is not accurate. It's no longer NULL, it's set to a string that contains the word NULL.
What am I missing here?
The correct SQL syntax to set a column to NULL is:
UPDATE Table SET Column = NULL WHERE . . .
(note the lack of quotes around the literal NULL).
Are you performing this UPDATE using SQL or using some kind of framework? If a framework, it should recognize NULL values and pass them to the database correctly for you.
After a lot of research, I've found that this is a well known problem with no good solution if you are writing your sql queries outright.
The correct solution is to use a database abstraction layer like PDO ( for PHP ), or Active Record ( used in frameworks like Codeignitor and Ruby on Rails ).

Unknown character set index for field received from server

I have an instance of MySQL 5.0.4.1 with an application written in Hibernate. On one of the pages, I get the following error message in the server log:
Unknown character set index for field '123' received from server.at com.mysql.jdbc.Connection.getCharsetNameForIndex(Connection.java:1664)at com.mysql.jdbc.Field.(Field.java:144)at com.mysql.jdbc.MysqlIO.unpackField(MysqlIO.java:506)at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:280)at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1319)at com.mysql.jdbc.MysqlIO.sqlQuery(MysqlIO.java:1218)at com.mysql.jdbc.Connection.execSQL(Connection.java:2233)at com.mysql.jdbc.Connection.execSQL(Connection.java:2193)at com.mysql.jdbc.Connection.execSQL(Connection.java:2174)at com.mysql.jdbc.Connection.setAutoCommit(Connection.java:536)at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setAutoCommit(PoolingDataSource.java:293)at org.hibernate.transaction.JDBCTransaction.toggleAutoCommit(JDBCTransaction.java:194)at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:186)at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:162)at org.springframework.orm.hibernate3.HibernateTransactionManager.doRollback(HibernateTransactionManager.java:603)at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:579)at org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:556)at org.springframework.transaction.interceptor.TransactionAspectSupport.doCloseTransactionAfterThrowing(TransactionAspectSupport.java:284)at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:100)at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)at org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:66)at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)at org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:66)at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)at $Proxy6.getDataFromDatabase(Unknown Source)at org.myCompany.myAction.load(Unknown Source)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:274)at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:194)at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)at javax.servlet.http.HttpServlet.service(HttpServlet.java:787)at javax.servlet.http.HttpServlet.service(HttpServlet.java:908)at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:280)at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:209)at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:157)at com.iplanet.ias.web.WebContainer.service(WebContainer.java:579)
This error occurs on a production environment so I don't know which query produced the problem, but I do know that none of my tables has a column named '123'. Do you have any suggestions about what might be causing this problem?
Edit: As a followup, I found that this behavior is a known bug in MySQL 5.0.4, but I haven't found a good wokaround since I don't have the option of upgrading mySQL.
Could be that somehow the character set for the field has been set to an invalid value, run this SQL on the server with the problem replacing the table name and the column 'Collation' will show the characterset for each varchar/char fields
SHOW FULL COLUMNS IN table_name;
You can then change the character set of a field by using the following:
ALTER TABLE t MODIFY col1 VARCHAR(50) CHARACTER SET latin1;
Internally, MySQL is mapping out the indexes across the columns. Normally this is done using integers that represent the column index. Most indexes are actually a compound index once built (col 1 + col 3) which form something like field 13.
Likely this happened when migrating data from dev into production when the stack is not an exact replica.
As 3urdoch mentioned you can pull the charset using internal MySQL function; and then change the table's charset to a compatible encoding.
Alternatively (where I'm willing to bet this issue came from) you can check if the loaded driver for the Production matches the loaded driver for the Other server. This will prevent re-occurring issue if the Development/Other server is still being used for testing, and migrated into Production.