I am looking forward for a configuration changes at ngpsql level which converts boolean value(true/false) from .Net Application to bit value(1,0) for PostgreSQLoperation. The User inputs true/false from GUI.This has to be converted to 1 or 0 as PostgreSQL supports only 1 and 0 as bit values. Can this mapping be achieved during npgsql level ?
npsql version 4.0
Visual studio 2015
Related
So in Access you can choose the column data type "Yes/No" and it will ask you while typing in the information the option "Yes" and "No". Yet, I do not see any of that on SQL Server Management Studio from Microsoft, I've searched around and seen that "bit" is the type, but when I put bit and I go to add information it appears as a normal column to type information. Or should I know myself to put either 0 or 1?
Also, is 0 true or false?
SQL Server doesn't have a boolean data type. The closest approximation is the bit. But that is a numeric type, not a boolean type. In addition, it only supports 2 values - 0 or 1 (and one non-value, NULL).
However, SQL (standard SQL, as well as T-SQL dialect) describes a Three valued logic - TRUE, FALSE and UNKNOWN. So bit isn't actually the best if you need all 3 states.
When using it, you cannot use that value directly in an if statement for example:
IF CONVERT(bit, 0)
BEGIN
print 'Ok'
END
would not parse and end up in error. So, you would need to write it as below;
IF CONVERT(bit, 0) = 0
In MS SQL bit is equivalent to a boolean.
https://msdn.microsoft.com/en-us/library/ms177603.aspx
Here you can read more about.
1 would be the equivalent of Yes
0 would be the equivalent of No
NULL would be the equivalent of Undefined ( if that exists in Access )
in SQL Server the equivalent to boolean datatype is Bit. Bit can take values 0(false) or 1 (true). If you want to set a default value to your Bit field on creating the table you can set:
...
myBoolean Bit, default 1,
..
I'm mapping a column in a DBML to a bit column in SQL Server. Which of the following should "Type" (not server data type) in the DBML be marked as:
Binary (System.Data.Linq.Binary)
boolean
byte
From the MSDN reference http://msdn.microsoft.com/en-us/library/ms177603.aspx, for bit on MSSQL
"The string values TRUE and FALSE can be converted to bit values: TRUE is converted to 1 and FALSE is converted to 0."
Going by that logic, I would use boolean for your mapping.
NOTE: This is a pretty commonly discussed question on forums, including stack overflow. I'm certain there is a more comprehensive answer available.
I found a more comprehensive answer:
C# Equivalent of SQL Server DataTypes
I'm trying to load third party XSD Scheme to my SQL Server 2008 throught "create xml schema collection" statement
There is a complex type based on "xs:decimal" with restrictions:
<xs:totalDigits value="31"/>
<xs:fractionDigits value="14"/>
inside the XSD.
And SQL Server returns error
Msg 6960, Level 16, State 2, Line 2
Component 'NAME' is outside of allowed range. Maximum for 'fractionDigits' is 10 and maximum number of digits for non fractional part is 28
But I still able to create a variable with type "numeric(31,14)"
I didn't find any restrictions neither on w3c documentations nor in MSDN. Can you please guide me to some documentation on this restrictions. May be I can fix it with some Service Pack or Setting.
SQL Server version: Microsoft SQL Server 2008 (SP3) - 10.0.5500.0 (X64) Sep 21 2011 22:45:45 Copyright (c) 1988-2008 Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)
I found an answer on the MSDN (http://msdn.microsoft.com/en-us/library/ms190665(v=sql.100).aspx)
SQL Server does not support variable precision decimals. The
xs:decimal type represents arbitrary precision decimal numbers.
Minimally conforming XML processors must support decimal numbers with
a minimum of totalDigits=18. SQL Server supports totalDigits=38, but
limits the fractional digits to 10. All xs:decimal instanced values
are represented internally by the server by using the SQL type numeric
(38, 10).
They map xs:decimal not to numeric type, but decimal
I found an answer on the MSDN (http://msdn.microsoft.com/en-us/library/ms190665(v=sql.100).aspx)
SQL Server does not support variable precision decimals. The
xs:decimal type represents arbitrary precision decimal numbers.
Minimally conforming XML processors must support decimal numbers with
a minimum of totalDigits=18. SQL Server supports totalDigits=38, but
limits the fractional digits to 10. All xs:decimal instanced values
are represented internally by the server by using the SQL type numeric
(38, 10).
They map xs:decimal not to numeric type, but decimal
This answer to what looks like the same question:
Convert integer to hex and hex to integer
..does not work for me.
I am not able to go to a HEX string to an integer using MS SQL server 2005 CAST or CONVERT. Am I missing something trivial? I have searched extensively, and the best I can find are long-winded user functions to go from a hex string value to something that looks like a decimal int. Surely there is a simple way to do this directly in a query using built in functions rather than writing a user function?
Thanks
Edit to include examples:
select CONVERT(INT, 0x89)
works as expected, but
select CONVERT(INT, '0x' + substring(msg, 66, 2)) from sometable
gets me:
"Conversion failed when converting the varchar value '0x89' to data type int."
an extra explicit CAST:
select CONVERT(INT, CAST('0x89' AS VARBINARY))
executes, but returns 813185081.
Substituting 'Int', 'Decimal', etc for 'Varbinary' results in an error. In general, strings that appear to be numeric are interpreted as numeric if required, but not in this case, and there does not appear to be a CAST that recognizes HEX. I would like to think there is something simple and obvious and I've just missed it.
Microsoft SQL Server Management Studio Express 9.00.3042.00
Microsoft SQL Server 2005 - 9.00.3080.00 (Intel X86) Sep 6 2009 01:43:32 Copyright (c) 1988-2005 Microsoft Corporation Express Edition with Advanced Services on Windows NT 5.1 (Build 2600: Service Pack 3)
To sum up: I want to take a hex string which is a value in a table, and display it as part of a query result as a decimal integer, using only system defined functions, not a UDF.
Thanks for giving some more explicit examples. As far as I can tell from the documentation and Googling, this is not possible in MSSQL 2005 without a UDF or other procedural code. In MSSQL 2008 the CONVERT() function's style parameter now supoprts binary data, so you can do it directly like this:
select convert(int, convert(varbinary, '0x89', 1))
In previous versions, your choices are:
Use a UDF (TSQL or CLR; CLR might actually be easier for this)
Wrap the SELECT in a stored procedure (but you'll probably still have the equivalent of a UDF in it anyway)
Convert it in the application front end
Upgrade to MSSQL 2008
If converting the data is only for display purposes, the application might be the easiest solution: data formatting usually belongs there anyway. If you must do it in a query, then a UDF is easiest but the performance may not be great (I know you said you preferred not to use a UDF but it's not clear why). I'm guessing that upgrading to MSSQL 2008 just for this probably isn't realistic.
Finally, FYI the version number you included is the version of Management Studio, not the version number of your server. To get that, query the server itself with select ##version or select serverproperty('ProductVersion').
I've managed to connect from SBCL running on debian to an SQL Server 2000 instance over the network using FreeTDS/unixODBC.
I can actually get data back from the server, so all is working.
However, many of the columns trigger what seem to be unsupported data types a-la:
The value 2147483647 is not of type FIXNUM.
and
-11 fell through ECASE expression.
Wanted one of (-7 -6 -2 -3 -4 93 92 91 11 10 ...).
Anyone have experience using CLSQL with SQL Server would be able to help out?
This (error with 2147483647) occurs because the FreeTDS driver doesn't handle OLEDB BLOBs so well.
You have to issue the following SQL command to make it work:
set textsize 102400
You can see the FreeTDS FAQ entry here. Excerpt:
The text data type is different from char and varchar types. The maximum data length of a text column is governed by the textsize connection option. Microsoft claims in their documentation to use a default textsize of 4000 characters, but in fact their implementation is inconsistent. Sometimes text columns are returned with a size of 4 GB!
The best solution is to make sure you set the textsize option to a reasonable value when establishing a connection.
As for the ECASE expression, I haven't really solved it but I have hacked it away by doing a data conversion of timestamp into a binary value, and a uniqueidentifier into a varchar(36).