If I query for a mediumint column from a MySQL table through jdbc, what type would I get back in the ResultSet object?
Or would that be an error?
(I know JDBC's Types.java doesn't have MEDIUMINT).
You can use almost any Java Type (look here) but the best way is to use Integer, since Short would be to short for MEDIUMINT and to get back the result you should use the method rs.getInteger("COLUMNNAME")
Not an error. The column type as returned by ResultSetMetaData.getColumnType() is 4, INTEGER. If you invoke ResultSet.getObject(), you'll get a java.lang.Integer. Invoking getInt() or getLong() will both work just fine.
The type returned by the JDBC driver, if not represented as part of the JDBC specification itself (the infamous table in Appendix B), will be the smallest Java type that can represent the full range of values of the MySQL type.
Related
My JPA entity has a UUID attribute, which is stored as char(36) in mysql. When I query data i'm receving 66323735-3039-6262-2d31-3764392d3466 instead of f27509bb-17d9-4f37-b336-8603f2d34394. When I enabled hibernate logs, I could see
org.hibernate.type.descriptor.sql.BasicExtractor - extracted value ([col_1_0_] : [BINARY]) - [66323735-3039-6262-2d31-3764392d3466]
extracted value is [BINARY] instead of [VARCHAR] like other attributes.
Any clue as to why this is happening?
Also,
I've tried to run hibernate generated query on mysql and that returns correct results.
Other column values including UUIDs are being returned correctly.
I'm using an interface based entity projection to retrieve limited data and not the whole entity.
edit: I just added trim(colName) and now it's returning correct UUID value. But still not sure of the issue at hand.
Do this for hibernate 6. It will generate character type (for mysql char(36)).
#org.hibernate.annotations.JdbcTypeCode(SqlTypes.CHAR)
protected UUID id;
The query executed should match the story_id with the provided string but when I execute the query it's giving me a wrong result. Please refer to the screenshot.
story_id column in your case is of INT (or numeric) datatype.
MySQL does automatic typecasting in this case. So, 5bff82... gets typecasted to 5 and thus you get the row corresponding to story_id = 5
Type Conversion in Expression Evaluation
When an operator is used with operands of different types, type
conversion occurs to make the operands compatible. Some conversions
occur implicitly. For example, MySQL automatically converts strings to
numbers as necessary, and vice versa.
Now, ideally your application code should be robust enough to handle this input. If you expect the input to be numeric only, then your application code can use validation operations on the data (to ensure that it is only a number, without typecasting) before sending it to MySQL server.
Another way would be to explicitly typecast story_id as string datatype and then perform the comparison. However this is not recommended approach as this would not be able to utilize Indexing.
SELECT * FROM story
WHERE (CAST story_id AS CHAR(12)) = '5bff82...'
If you run the above query, you would get no results.
you can also use smth like this:
SELECT * FROM story
WHERE regexp_like(story_id,'^[1-5]{1}(.*)$');
for any story_ids starting with any number and matching any no of charatcers after that it wont match with story_id=5;
AND if you explicitly want to match it with a string;
I have a database and a bigint column type. Everytime I insert value to this column I always got the wrong number. for example, I insert value "198705122006041001" and it always insert this value "2147483647".
I use laravel for my project, if I use eloquent to display the bigint it wont display correctly but if I use PDO manually, it will display correctly.
PHP has no bigint data type, it overwflows and uses int.max instead. You have to represent bigints as string or float. Be aware, that float is not precise and can lead to surprises.
Do the mathematical transformations in MySQL and don't forget to cast to bigint when necessary.
You should check this again, because it's definitely int, but not bigint. 2147483647 is a maximum possible value for signed int
See https://laracasts.com/discuss/channels/eloquent/fbid-bigint-with-model-and-eloquent. A Laravel user had the same problem, and eventually had to cast the result to a string.
Another user comment pointed out that XAMPP provides only a 32-bit PHP binary, which limits the size of a PHP integer.
Check your PHP integer size with this code:
<?php
echo "Integer size can be determined using the constant PHP_INT_SIZE="
. (PHP_INT_SIZE * 8)
. " bits, maximum value using the constant PHP_INT_MAX="
. PHP_INT_MAX;
See also http://php.net/manual/en/language.types.integer.php
Install https://laravel.com/docs/5.3/homestead and get a 64-bit PHP binary.
This is really simple. Does SQL SERVER 2008 auto convert values to string for you ?
I tried this Select * from Staff Where Division = 5
If I try to insert it, it works too.
If I change 5 for five I get and error though. Invalid column name five.
Division is a NVARCHAR. Shoudn't the 5 be within single quotes ?
Yes, SQL Server does an implicit conversion of int to nvarchar. It can also implicitly convert nvarchar to int (and other numeric types).
For more details: http://msdn.microsoft.com/en-us/library/ms191530.aspx
There are a lot of cases where implicit conversion takes place. For example:
EXEC sp_who2 active;
Shouldn't you need to delimit active as a string? Yes, but the syntax is forgiving.
My suggestion: always delimit data types correctly, and ignore the exceptions. The chances they'll ever get comprehensively fixed are close to nil.
So I am currently working on a migration from an old Advantage database server to SQL 2005 using SSIS 2008. One of the columns in the old Advantage database is a MEMO type. By default this translates to a DT_TEXT column. Well in the new database I do not need this large of field, but can limit it to something such as VARCHAR(50). I successfully set up a derived column transformation to convert this with the following expression:
(DT_STR,50,1252)[ColumnName]
Now I want to go a step further and replace all NULL values with an empty string. This would seem easy enough using an ISNULL([ColumnName])?"":(DT_STR,50,1252)[ColumnName] expression, but the problem is that the OLE DB Destination contains the following error
Cannot convert between unicode and non-unicode strings...
So apparently the whole ISNULL expression converts the data type to Unicode string [DT-WSTR]. I have tried a variety of casts upon the whole expression or different parts, but I cannot get the data type to match what I need it.
First, is it possible to convert the DT_TEXT type directly to unicode? From what I can tell, the casts don't work that way. If not, is there a way to get an expression to work so that NULL values get converted to empty strings?
Thank you for all your help!
Give this a try in your derived column.
(DT_STR,50,1252) (ISNULL(ColumnName) ? "" : (DT_STR,50,1252) ColumnName)
It includes an additional type cast with the Conditional (?:) in parentheses to ensure the desired processing sequence. I think your original expression was implicitly casting to DT_WSTR because the "" defaults to DT_WSTR. With this new version, you force the cast to DT_STR after the expression is evaluated.
I figured something out that works. It may not be the best solution, but it will work for my situation.
From my OLE DB source I first did a Derived Column. This I used the ISNULL which ended up converting it to a DT_WSTR unicode type. although I could not get any casts to get it back to the type required, I then added a Data Conversion transformation in-between the Derived Column and the OLE DB Destination. This would take the input string and convert it back to a DT_STR. This all feels a little annoying converting so many times, but the column does not contain any funky information that I should have to worry about, so I suppose it will work.
Thanks for all those who pondered the solution, and if you find some awesome way to tackle it, I would be more than interested.