Here's the problem. In MySQL's Connector/NET a TINYINT(1) field properly translates back and forth into a .NET bool value. If I select from a table with a TINYINT(1) column, everything is golden. However, when you use built-in MySQL v5.0 functions like:
SELECT (3 BETWEEN 2 AND 4) AS oddly_not_boolean;
The actual return type from the database registers this field as INT or BIGINT, which Connector/.NET obviously doesn't convert to bool. MySQL CAST() and CONVERT() do not allow casting to TINYINT(1).
I've even gone so far as to try a user function to do this, but this doesn't work either (EDIT: this does work):
CREATE FUNCTION `to_bool`(var_num BIGINT)
RETURNS TINYINT(1) RETURN var_num;
How do I convert an INT to a TINYINT(1) in a query in MySQL?
EDIT: The above function DOES actually work to convert the value to a TINYINT(1), but my Connector/NET is just bugged and doesn't properly convert the values from functions.
UPDATE 2009-11-03: Updated my connector and it's still giving me back Int32. Further testing reveals that this is an InnoDB bug in MySQL 5.0.x that only shows under specific circumstances.
Related
I am coming back to SQLite after an absence of many years. My understanding of SQLite has always been that it has a rather simple set of data types - INTEGER, REAL, TEXT, BLOB & NULL and indeed this page suggests exactly that.
However, I just looked at the command line tutorial on the SQLite site where it immediately starts talking about varchar smallint etc. Is this merely the result of some sloppy documentation or does the current version of SQLite offer a mySQLesque cacophony of data types?
The smallint and varchar types are listed on the SQLite data-types page:
https://www.sqlite.org/datatype3.html
smallint is an INTEGER
varchar(n) is TEXT
I am trying to declare a table using SQLAlchemy. I'd like to include a BIGINT auto incrementing primary key in the table. This does not seem to work with sqlite as the DB backend. On the other hand, having INTEGER auto incrementing primary key works just fine.
I read that sqlite has ROWID that is a signed bigint. But is there a way to have a BIGINT auto increment field? This way I can swap backends without worrying about db specific issues (assuming MySQL and Postgres support bigint auto incrementing fields).
Thanks.
For others who get here via Google and just need a solution I have written the following code:
# SQLAlchemy does not map BigInt to Int by default on the sqlite dialect.
# It should, but it doesnt.
from sqlalchemy import BigInteger
from sqlalchemy.dialects import postgresql, mysql, sqlite
BigIntegerType = BigInteger()
BigIntegerType = BigIntegerType.with_variant(postgresql.BIGINT(), 'postgresql')
BigIntegerType = BigIntegerType.with_variant(mysql.BIGINT(), 'mysql')
BigIntegerType = BigIntegerType.with_variant(sqlite.INTEGER(), 'sqlite')
This will allow you to use BIGINT on a database, and INT for when you run unit tests.
Sqlite doesn't allow BIGINT used as an primary key with autoincrement.
But, due to dynamic nature of sqlite column types, you can make a backend-specific column type and use INTEGER type in case of sqlite backend, see SQLAlchemy: How to conditionally choose type for column by depending on its backend.
Hope that helps.
I have a DB in a Rails app I'm developing that had a product_type field defined as varchar(255) (in SQLite Manager) that ended up being a foreign key. I changed the name to product_type_id and the type to integer using a migration in Rails to use the existing id field in the other product_type file. When it was complete, SQLite Manager in Firefox shows the type as integer(255) rather than just integer.
What is an integer(255)? An answer to another question here said the (255) was a display width. Is that correct? There is no data in the database at present. Should I delete and recreate the field to get an integer, otherwise the data types on the two fields won't match.
The integer(255) came about because a string field [ varchar(255) ] was converted to an integer and the DB maintained the field size so it might possibly hold the old data when converted during the change. Apparently, most DBs don't support integers that large. Some will ignore the size specification but others will error. Regardless, the result was not what I'd intended.
I found that the way to remove the limit was to perform a migration in Rails and set the limit to nil.
class RemoveIntegerLimits < ActiveRecord::Migration
def up
change_column :inv_x_refs, :company_id, :integer, limit: nil
end
end
I am using MySQL 5.5 and i linked it with my ASP.net Application .
i added a dataset to link my application within the MySQL stored procedure !!!
the problem is when i call any stored procedure which contains BOOLEAN like this one :
CREATE DEFINER=`root`#`localhost` PROCEDURE `SpCatDetailsDML`(
ParDetDescription TEXT,
ParDetDescriptionAR TEXT,
ParPrice INT,
ParCreatedOn DATETIME,
ParDisplayOrder INT,
ParAllowDisplay BOOLEAN,
ParPictureID BIGINT,
ParShowTypeID BIGINT
)
BEGIN-- INSERT --
INSERT INTO cms.tbcatdetails(CatID,CustomerID,DetTitle,DetTitleAR,ShoertDesc,ShoertDescAr,DetDescription,
DetDescriptionAR,Price,CreatedOn,DisplayOrder,AllowDisplay,PictureID,ShowTypeID)
VALUES (ParCatID,ParCustomerID,ParDetTitle,ParDetTitleAR,ParShoertDesc,ParShoertDescAr,ParDetDescription,
ParDetDescriptionAR,ParPrice,ParCreatedOn,ParDisplayOrder,ParAllowDisplay,ParPictureID,ParShowTypeID);
END
when i add this stored procedure to my dataset it will show me a warning becaues th ParAllowDisplay data type which is Boolean!!
so any suggestions???
There is no Boolean data type in MySQL. Use TINYINT(1) instead.
See here http://dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html
weird, I see BOOL, BOOLEAN in the URL mentioned above. Never used them.
also, refer this post Which MySQL data type to use for storing boolean values
I am using Full Text Search with LINQ in my application and as this is not supported by LINQ I use a table-valued function workaround. The function is created on SQL Server 2008.
Surprisingly, I get error “The full-text query parameter for Fulltext Query String is not valid” when I search for a simply text e.g. “manager”
I used SQL Server Profiler and found out that LINQ generated the parameter as nvarchar(4000) instead of nvarchar(250) which is in my function.
The biggest surprise came when I changed my SQL Server function so it accepts parameter as nvarchar(4000) instead of nvarchar(250) and the problem is solved.
I was also playing to change the parameter to nvarchar(2000) and less but this also didn’t work.
Does anybody know why this behaves this way?
Updated on 18th November 2013 - Good news and bad news
Good news - I am now using Entity Framework 6 for this particular example and it is not anymore needed to use nvarchar(4000)
Bad news - You have to use instead nvarchar(max) :-(
For an expanation see the following link http://social.msdn.microsoft.com/Forums/en-US/linqtosql/thread/1a46d676-32f0-44a4-b39f-61a17bccb8e3/.
In my case I had to force JAVA to call my Table-Value-Function with matching datatype as below
query.setParameter(0, variable, new **StringNVarcharType**() )
You need to ensure the size of the varchar (or nvarchar) variables are the same in your sql function and where they are declared.
In my case I had a function that declared the variable as nvarchar(100) but the stored procedure that called the function declared the variable passed in as nvarchar(200). Changing the function to be the same as the stored procedure variable fixed this.
Code below shows the non-working case with the inconsistently sized nvarchars.
CREATE FUNCTION [dbo].[udf_FullTextSearch](#searchExpression nvarchar(100))
RETURNS TABLE
AS
RETURN
SELECT *
FROM Company c
WHERE contains(c.Name, #searchExpression)
GO
DECLARE #searchExpression nvarchar(200) = '"ltd"'
SELECT * FROM [dbo].[udf_FullTextSearch](#searchExpression)