I have a bit column in the SQL Server 2008 database and I am trying to use Dapper to map it to my object that has boolean fields that match the bit columns. I get invalid cast exceptions as Dapper is trying to say the columns are ints. How do I get it to map a bit to a bool? Also, will there ever be decent documentation for this ORM?
I found the problem. The stored procedure was using coalesce on the column which was casting it as an int.
Is the column nullable ? If this is the case try to structure the dto with a property of type bool? instead of just bool, to handle the DbNull value correctly. The better documentation is the code itself and the project home.
Related
I'm trying to export data from SQL Server to flat files.
The data includes a bit column 0/1 and I need it as is but it get exported as Boolean TRUE/FALSE which is causing ETL bulk insert to fail.
I tried changing the data mapping to single byte integer, float, numeric, string, text hoping to get a simple 0/1 but nothing worked.
Any pointers on how to solve this are appreciated (other than replacing text within the resulted file).
Add a IIF in your select to convert Boolean to 0/1 to export:
SELECT Name, Code
,IIF(EuroZone = 1, 1, 0) AS EuroZone
,IIF(Visible= 1, 1, 0) AS Visible
FROM your_table
The problem is, SQL Server has a bit data type. It does not have a boolean, while SSIS
uses .Net data types, not SQL data types. It supports boolean, not bit. Though it has built-in conversions, to resolve problems like that. So in my opinion, you need to use a derived column to solve that.
I'm trying to use the ADO Filter property to filter a Recordset with a uniqueidentifier column. I'm connecting to SQL Server 2008 using ADO on Windows 7, using the SQLOLEDB.1 provider.
I create a Recordset and use it to send the SQL query to the server. Then I set the ADO Recordset.Filter property. I get errors no matter what I've tried for the Filter.
If I try
[column name] = '5D9C83FB-E758-0D4B-B1C7-E751D951B67C'
I get
Filter cannot be opened.
If I try
[column name] like '%5D9C83FB-E758-0D4B-B1C7-E751D951B67C%'
I get
Invalid class string.
(Note: I've left out any required double-quotes for clarity. I'm able to search other types of string columns so the quoting isn't the problem.)
I am using Delphi XE2, but I think that's probably not relevant as I'm creating my ADO object directly rather than use any of their wrapper code. I have no problem with the Filter property on any of the various string type columns, just uniqueidentifier.
My basic question is if you can make this work, how do you do it (short of converting the column to a string during querying)? The more general question is what are the rules around using uniqueidentifier columns with the Filter property. I couldn't find anything relevant.
In both of those cases you're treating them like strings. I suggest trying wrapping the GUID value in curly braces:
[column name] = '{5D9C83FB-E758-0D4B-B1C7-E751D951B67C}'
In Delphi (and most other frameworks), you cannot filter GUID locally in a RecordSet with syntax similar to LIKE with strings. To the frameworks, GUIDs are just a bunch of bytes, not a string.
You have to do the filtering on the server side using the LIKE syntax that SQL Server itself supports (an example of the syntax is in How to use SQL's LIKE on a guid in Entity Framework?).
What is the difference between the Sqlxxx datatypes and their .NET equivalents?
For instance, why and when should I use SqlString and not string?
Whenever possible, you should use the SqlTypes types for SQLCLR method parameters. There are only 4 SQL Server datatypes that do not have a matching Sql***** type:
TIME: use TimeSpan or TimeSpan?
DATETIME2: use DateTime or DateTime?
DATETIMEOFFSET: use TimeZoneOffset or TimeZoneOffset?
SQL_VARIANT: use object (NULL comes through as DbNull.Value)
For more info, see the following MSDN page: Mapping CLR Parameter Data
Some differences between SqlString and string (that are important in certain situations) are that SqlString:
retains the encoding as defined by the default COLLATION of the database where the Assembly exists, and
contains properties describing the LCID and SqlCompareOptions (i.e. case sensitivity, accent sensitivity, etc) as defined by the default COLLATION of the database where the Assembly exists. Using string (or even SqlChars) would lose this info.
has methods to return a byte[] -- GetUnicodeBytes and GetNonUnicodeBytes -- whereas string has ToCharArray. NVARCHAR source data is encoded as UTF-16, which will use either 2 bytes or 4 bytes for each character, depending on the character.
properly handles T-SQL NULLs. This can be tested for via the IsNull boolean property (that all of the Sql* types have). When passing back as a return value or column value for a TVF, use the static property SqlString.Null (which all of the Sql* types have).
When it comes to sending in large values in NVARCHAR(MAX) and VARBINARY(MAX) parameters, you can actually stream the values from SQL Server into SQL Server's CLR by using the SqlChars and SqlBytes types, respectively. There are some use cases where streaming is much more efficient (assuming you don't need the entire value at one time). Also, if the parameter is never accessed, then none of the data is sent over at all, unlike when using SqlString and SqlBinary, respectively.
Related information can be found in an article I wrote for a series on SQLCLR: Stairway to SQLCLR Level 5: Development (Using .NET within SQL Server) (free registration is required).
A big difference is the null handling and collation. Look at the below link.
I suggest using the sqlclr types for parameters and return types.
You can typically work with these types in the whole function body.
http://msdn.microsoft.com/en-us/library/ms131049(v=sql.100).aspx
I have a field in a SQL Server table that is of type bit.
When I try to use a Boolean in VB.NET when passing parameters to a stored procedure, there are never any matches. I have also tried passing an integer to the stored procedure and that does not work either.
have a look at this table:
http://msdn.microsoft.com/en-us/library/ms131092.aspx
How about
SqlDbType.Bit
System.Data.SqlTypes.SqlBoolean
Can a Linq query retrieve BLOBs from a Sql Database?
And how do they come out?
LINQ-To-SQL classes create properties of type System.Data.Linq.Binary for all binary and varbinary fields in SQL-Server. The Binary type has a .ToArray() method that returns a byte[], and its constructor can take a byte[].
Older versions of SQLMetal generated properties of type byte[], but the problem with these was that they failed in any joins. I think that's the main reason they replaced it with the IEquatable Binary type.
If I'm not mistaken LINQ to SQL teats BLOB as System.Byte[]
I recall that there was some problem with SqlMetal, it generated wrong type for BLOB, but MSVS dmbl designer should work.