Showing posts with label types. Show all posts
Showing posts with label types. Show all posts

Friday, March 30, 2012

Mapping SQL Server Data Types to C DataTypes

Hi Can anyone point me to a document somewhere that shows a mapping of
SQL Server 2000 datatypes to C datatypes? I am writing some extended
stored procedures which need to be able to process pretty much any
data type, so I want to make sure I am taking them from SRVPROC and
storing them in the correct C data type.

Thanks,
Bruce[posted and mailed, please reply in news]

Bruce (sandell@.pacbell.net) writes:
> Hi Can anyone point me to a document somewhere that shows a mapping of
> SQL Server 2000 datatypes to C datatypes? I am writing some extended
> stored procedures which need to be able to process pretty much any
> data type, so I want to make sure I am taking them from SRVPROC and
> storing them in the correct C data type.

Books Online.

Building SQL Server Applications.
Extended Stored Procedures Programming
Extended Stored Procedure Programmer's Reference
Data Types (the last topic).

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Wednesday, March 28, 2012

Mapping of SQL Server data types to Integration Services Data Type

Does anyone know of any cross-references between SQL Server data types and the new data types introduced with SQL Server Integration Services?

For example, Integration Services has "DT_DATE", "DT_DBDATE", "DT_DBTIME" and "DT_DBTIMESTAMP". So far, if I have a SQL Server datetime column, the only Integration Services type I have been able to use is "DT_DBTIMESTAMP". There must be a way to map the datetime type to "DT_DATE", "DT_DBDATE" and "DT_DBTIME", but there no easy to use reference for this.

Please post a link to the resources if you know of one.

Thanks.We are just in the process of refining such a topic for the around-RTM Web refresh of Books Online. Copying and pasting HTML out of BOL is usually a disaster, but I'll give it a try, below. It will look more user-friendly when it appears in BOL! This topic has not been fully edited and tech reviewed - use at your own risk.

-Doug

Mapping Data Types in the Data Flow

While moving data from sources through transformations to destinations, a data flow component must sometimes convert data types between the SQL Server 2005 Integration Services (SSIS) types defined in the DataType enumeration and the managed data types of the Microsoft .NET Framework defined in the System namespace. In addition, a component must sometimes convert one Integration Services data type to another before that type can be converted to a managed type.

Note: The mapping files in XML format that are installed by default to C:\Program Files\Microsoft SQL Server\90\DTS\MappingFiles are not related to the data type mapping discussed in this topic. These files map data types from one database version or system to another (for example, from SQL Server 2000 to SQL Server 2005, or from SQL Server 2005 to Oracle), and are used only by the SQL Server Import and Export Wizard.

Mapping between Integration Services and Managed Data Types

Sometimes a data flow component must convert data types between the SQL Server 2005 Integration Services (SSIS) types defined in the DataType enumeration and the managed data types of the Microsoft .NET Framework defined in the System namespace. The following table lists the conversions that are currently performed by the BufferTypeToDataRecordType and the DataRecordTypeToBufferType methods of the PipelineComponent class. Other Integration Services data types not listed here cannot be converted to managed types.

Caution: Developers should use these methods of the the PipelineComponent class with caution, and may want to code data type mapping methods of their own that are more suited to the unique needs of their custom components. The existing methods do not consider numeric precision or scale, or any other properties closely related to the data type itself. Microsoft may modify or remove these methods, or modify the mappings that they perform, in a future version of Integration Services.

Integration Services Data Type Managed Data Type DT_WSTR System.String DT_BYTES Array of System.Byte DT_DBTIMESTAMP System.DateTime DT_NUMERIC System.Decimal DT_GUID System.Guid DT_I1 System.Byte DT_I2 System.Int16 DT_I4 System.Int32 DT_I8 System.Int64 DT_BOOL System.Boolean DT_R4 System.Single DT_R8 System.Double DT_UI1 System.Byte DT_UI2 System.UInt16 DT_UI4 System.UInt32 DT_UI8 System.UInt64

Converting Integration Services Data Types to Fit Managed Data Types

Sometimes a data flow component must also convert one Integration Services data type to another before that type can be converted to a managed type. The following table lists the conversions that are currently performed by the ConvertBufferDataTypeToFitManaged method of the PipelineComponent class.

Caution: Developers should use these methods of the the PipelineComponent class with caution, and may want to code data type mapping methods of their own that are more suited to the unique needs of their custom components. The existing methods do not consider numeric precision or scale, or any other properties closely related to the data type itself. Microsoft may modify or remove these methods, or modify the mappings that they perform, in a future version of Integration Services.

Original Data Type Converted Data Type DT_DECIMAL DT_NUMERIC DT_DATE DT_DBTIMESTAMP DT_BOOL DT_I4 DT_TEXT DT_WSTR DT_STR DT_WSTR DT_IMAGE DT_BYTES

See Also

Reference

BufferTypeToDataRecordType
DataRecordTypeToBufferType
ConvertBufferDataTypeToFitManaged

|||This is a good start, thanks. I'll be mindful of the risks in using it.

Ken|||Let me clarify in particular that the sentence, "Other Integration Services data types not listed here cannot be converted to managed types." (already rewritten since that build of BOL) means "...by using these methods." That is, the API methods mentioned in that paragraph.|||

If you interested in mapping of tinyints have a look at my post

http://www.sqljunkies.com/WebLog/simons/archive/2006/02/24/tinyint_in_SSIS.aspx

sql

Mapping of SQL Server data types to Integration Services Data Type

Does anyone know of any cross-references between SQL Server data types and the new data types introduced with SQL Server Integration Services?

For example, Integration Services has "DT_DATE", "DT_DBDATE", "DT_DBTIME" and "DT_DBTIMESTAMP". So far, if I have a SQL Server datetime column, the only Integration Services type I have been able to use is "DT_DBTIMESTAMP". There must be a way to map the datetime type to "DT_DATE", "DT_DBDATE" and "DT_DBTIME", but there no easy to use reference for this.

Please post a link to the resources if you know of one.

Thanks.We are just in the process of refining such a topic for the around-RTM Web refresh of Books Online. Copying and pasting HTML out of BOL is usually a disaster, but I'll give it a try, below. It will look more user-friendly when it appears in BOL! This topic has not been fully edited and tech reviewed - use at your own risk.

-Doug

Mapping Data Types in the Data Flow

While moving data from sources through transformations to destinations, a data flow component must sometimes convert data types between the SQL Server 2005 Integration Services (SSIS) types defined in the DataType enumeration and the managed data types of the Microsoft .NET Framework defined in the System namespace. In addition, a component must sometimes convert one Integration Services data type to another before that type can be converted to a managed type.

Note: The mapping files in XML format that are installed by default to C:\Program Files\Microsoft SQL Server\90\DTS\MappingFiles are not related to the data type mapping discussed in this topic. These files map data types from one database version or system to another (for example, from SQL Server 2000 to SQL Server 2005, or from SQL Server 2005 to Oracle), and are used only by the SQL Server Import and Export Wizard.

Mapping between Integration Services and Managed Data Types

Sometimes a data flow component must convert data types between the SQL Server 2005 Integration Services (SSIS) types defined in the DataType enumeration and the managed data types of the Microsoft .NET Framework defined in the System namespace. The following table lists the conversions that are currently performed by the BufferTypeToDataRecordType and the DataRecordTypeToBufferType methods of the PipelineComponent class. Other Integration Services data types not listed here cannot be converted to managed types.

Caution: Developers should use these methods of the the PipelineComponent class with caution, and may want to code data type mapping methods of their own that are more suited to the unique needs of their custom components. The existing methods do not consider numeric precision or scale, or any other properties closely related to the data type itself. Microsoft may modify or remove these methods, or modify the mappings that they perform, in a future version of Integration Services.

Integration Services Data Type Managed Data Type DT_WSTR System.String DT_BYTES Array of System.Byte DT_DBTIMESTAMP System.DateTime DT_NUMERIC System.Decimal DT_GUID System.Guid DT_I1 System.Byte DT_I2 System.Int16 DT_I4 System.Int32 DT_I8 System.Int64 DT_BOOL System.Boolean DT_R4 System.Single DT_R8 System.Double DT_UI1 System.Byte DT_UI2 System.UInt16 DT_UI4 System.UInt32 DT_UI8 System.UInt64

Converting Integration Services Data Types to Fit Managed Data Types

Sometimes a data flow component must also convert one Integration Services data type to another before that type can be converted to a managed type. The following table lists the conversions that are currently performed by the ConvertBufferDataTypeToFitManaged method of the PipelineComponent class.

Caution: Developers should use these methods of the the PipelineComponent class with caution, and may want to code data type mapping methods of their own that are more suited to the unique needs of their custom components. The existing methods do not consider numeric precision or scale, or any other properties closely related to the data type itself. Microsoft may modify or remove these methods, or modify the mappings that they perform, in a future version of Integration Services.

Original Data Type Converted Data Type DT_DECIMAL DT_NUMERIC DT_DATE DT_DBTIMESTAMP DT_BOOL DT_I4 DT_TEXT DT_WSTR DT_STR DT_WSTR DT_IMAGE DT_BYTES

See Also

Reference

BufferTypeToDataRecordType
DataRecordTypeToBufferType
ConvertBufferDataTypeToFitManaged

|||This is a good start, thanks. I'll be mindful of the risks in using it.

Ken|||Let me clarify in particular that the sentence, "Other Integration Services data types not listed here cannot be converted to managed types." (already rewritten since that build of BOL) means "...by using these methods." That is, the API methods mentioned in that paragraph.|||

If you interested in mapping of tinyints have a look at my post

http://www.sqljunkies.com/WebLog/simons/archive/2006/02/24/tinyint_in_SSIS.aspx

mapping data types

I am building a .NET app that uses sqlDataReader.GetSchemaTable method. this
returns a table which includes the column "Provider Type" which is the
database data type of the column, however it is a numeric value, are the
mappings between these numeric values and the textual data type names
documented anywhere?
eg Money appears to be 9
and Date appears to be 15For SQL Server 2000, the systypes system table contains mappings between the
data type name and a number called 'xtype'. They don't seem to line up with
your observations though.
xtype Data type name
-- --
34 image
35 text
36 uniqueidentifier
48 tinyint
52 smallint
56 int
58 smalldatetime
59 real
60 money
61 datetime
62 float
98 sql_variant
99 ntext
104 bit
106 decimal
108 numeric
122 smallmoney
127 bigint
165 varbinary
167 varchar
173 binary
175 char
189 timestamp
231 sysname
231 nvarchar
239 nchar
"guy" wrote:

> I am building a .NET app that uses sqlDataReader.GetSchemaTable method. th
is
> returns a table which includes the column "Provider Type" which is the
> database data type of the column, however it is a numeric value, are the
> mappings between these numeric values and the textual data type names
> documented anywhere?
> eg Money appears to be 9
> and Date appears to be 15
>|||Mark,
hmmm interesting, so far i have found:-
2 bit
3 char
6 float
8 Int
9 money
15 smalldatetime
16 smallint
22 varchar
cheers
"Mark Williams" wrote:
> For SQL Server 2000, the systypes system table contains mappings between t
he
> data type name and a number called 'xtype'. They don't seem to line up wit
h
> your observations though.
> xtype Data type name
> -- --
> 34 image
> 35 text
> 36 uniqueidentifier
> 48 tinyint
> 52 smallint
> 56 int
> 58 smalldatetime
> 59 real
> 60 money
> 61 datetime
> 62 float
> 98 sql_variant
> 99 ntext
> 104 bit
> 106 decimal
> 108 numeric
> 122 smallmoney
> 127 bigint
> 165 varbinary
> 167 varchar
> 173 binary
> 175 char
> 189 timestamp
> 231 sysname
> 231 nvarchar
> 239 nchar
>
> "guy" wrote:
>

Monday, March 12, 2012

Manipulating Text,nText data types filed in tsql

I have to run a dynamic sql that i save in the database as a TEXT data type(due to a large size of the sql.) from a .NET app. Now i have to run this sql from the stored proc that returns the results back to .net app. I am running this dynamic sql with sp_executesql like this..

EXEC sp_executesql@.Statement,N'@.param1 varchar(3),@.param2 varchar(1)',@.param1,@.param2,
GO

As i can't declare text,ntext etc variables in T-Sql(stored proc), so i am using this method in pulling the text type field "Statement".

DECLARE@.Statement varbinary(16)
SELECT@.Statement = TEXTPTR(Statement)
FROM table1
READTEXT table1.statement@.Statement 0 16566

So far so good, the issue is how to convert @.Statment varbinary to nText to get it passed in sp_executesql.

Note:- i can't use Exec to run the dynamic sql becuase i need to pass the params from the .net app and Exec proc doesn't take param from the stored proc from where it is called.

I would appreciate if any body respond to this.

Yes, the limitation of using NTEXT as variable causes the problem. I know a workaround, but... you still need EXEC to warp the execution of sp_executesql. Read this:

sp_executesql and Long SQL Strings in SQL 2000
There is a limitation with sp_executesql on SQL 2000 and SQL 7, since you cannot use longer SQL strings than 4000 characters. (On SQL 2005, use nvarchar(MAX) to avoid this problem.) If you want to use sp_executesql despite you query string is longer, because you want to make use of parameterised query plans, there is actually a workaround. To wit, you can wrap sp_executesql in EXEC():

DECLARE @.sql1 nvarchar(4000),
@.sql2 nvarchar(4000),
@.state char(2)
SELECT @.state = 'CA'
SELECT @.sql1 = N'SELECT COUNT(*)'
SELECT @.sql2 = N'FROM dbo.authors WHERE state = @.state'
EXEC('EXEC sp_executesql N''' + @.sql1 + @.sql2 + ''',
N''@.state char(2)'',
@.state = ''' + @.state + '''')
This works, because the @.stmt parameter to sp_executesql is ntext, so by itself, it does not have any limitation in size.

You can even use output parameters by using INSERT-EXEC, as in this example:

CREATE TABLE #result (cnt int NOT NULL)
DECLARE @.sql1 nvarchar(4000),
@.sql2 nvarchar(4000),
@.state char(2),
@.mycnt int
SELECT @.state = 'CA'
SELECT @.sql1 = N'SELECT @.cnt = COUNT(*)'
SELECT @.sql2 = N'FROM dbo.authors WHERE state = @.state'
INSERT #result (cnt)
EXEC('DECLARE @.cnt int
EXEC sp_executesql N''' + @.sql1 + @.sql2 + ''',
N''@.state char(2),
@.cnt int OUTPUT'',
@.state = ''' + @.state + ''',
@.cnt = @.cnt OUTPUT
SELECT @.cnt')
SELECT @.mycnt = cnt FROM #result
You have my understanding if you think this is too messy to be worth it.

So you can break the NTEXT statement from your table into several NVARCHAR(4000) strings, then pass the strings as parameter for sp_executesql. The original wonderful artilc can be found here:

http://www.sommarskog.se/dynamic_sql.html

|||Thanks, I had to break the query into pieces to get this working.