SQL: What is the difference between normal SQL and T-SQL?


->What is the difference between SQL and T-SQL? Why would a company use one over the other?

ANSI SQL is the standard Structured Query Language. Most database vendors support SQL. T-SQL is Microsoft’s "flavor" of SQL; it is ANSI SQL with Microsoft’s extensions. A company could choose to use T-SQL over SQL if they have a database application that communicates with a MS SQL Server database only. Therefore a developer could use the "extras" for improved performance, ease of SQL coding, etc. A company could chose SQL because a front-end may have to communicate with several relational database management systems (RDBMs) therefore a programmer could rely on the fact that most database understand ANSI SQL.


è What is the difference between SQL, PL-SQL and T-SQL? Can anyone explain what the difference between these three are and a scenario where each would be relevantly used?

SQL is a query language to operate on sets. It is more or less standardized, and used by almost all relational database management systems: SQL Server, Oracle, MySQL, PostgreSQL, DB2, Informix, etc.

PL/SQL is a proprietary procedural language used by Oracle

TSQL is a proprietary procedural language used by Microsoft in SQL Server.

Procedural languages are designed to extend the SQL’s abilities while being able to integrate well with SQL. They are used to write stored procedures: pieces of code residing on the server to manage complex business rules that are hard or impossible to manage with pure set-based operations.


->What is the difference between normal SQL and T-SQL?

T-SQL is the SQL Server (and previously Sybase) version of SQL. It offers many extensions over standard ANSI SQL, which many people might call "normal" SQL.


SQL: stored procedure with xml data and parsing values

– Stored procedure taking XML as input parameter.

ALTER procedure [dbo].[InsertPcyandCntlInfo] @XMLDOC xml


DECLARE @JobID uniqueidentifier


DECLARE @PolicyId uniqueidentifier

DECLARE @PolicyVersion int

Contains logic to parse the xml and read values and assign it to variables.

SELECT @JobID = nref1.value(‘jobid[1]’, ‘uniqueidentifier’) ,@ReportID = nref1.value(‘reportid[1]’, ‘varchar(100)’) ,@PolicyId = nref.value(‘id[1]’,’uniqueidentifier’) , @PolicyVersion = nref.value(‘version[1]’, ‘int’)

FROM (SELECT @XMLDOC As ID)temptable CROSS APPLY ID.nodes(‘//parameter’) AS R(nref),(SELECT @XMLDOC As rootID)temptable1 CROSS APPLY rootID.nodes(‘//root’) AS R1(nref1)

After assign values to the variables, these variable are used to insert values for a table.

INSERT INTO [ReportJob_policyToStatement]







select @JobID JobID,

PM_Policy.PolicyID,PM_Policy.PolicyVersion,vReport_PolicyControlStatement.StatementID as ControlStatementID,vReport_PolicyControlStatement.StatementVersion, Heading ControlStatementName


vPolicyCompact AS PM_Policy with(nolock) INNER JOIN vReport_PolicyToStatement AS PM_PolicyStatement with(nolock)

ON PM_Policy.PolicyID = PM_PolicyStatement.PolicyID AND PM_Policy.PolicyVersion = PM_PolicyStatement.PolicyVersion

INNER JOIN vReport_PolicyControlStatement with(nolock) ON vReport_PolicyControlStatement.StatementID = PM_PolicyStatement.StatementID

where PM_Policy.PolicyID =@PolicyID and PM_Policy.PolicyVersion = @PolicyVersion

Execution of Stored proc with the xml as input parameter

C#: HintPath Vs Referencepath


As for the "Referece Path" or "Hint Path" in the VS.NET project’s setting
files, they’re all design-time /dev-time setting used by the IDE. As
described in the IDE’s help doc, "Reference Path" are used by the VS.NET
IDE to load all the assembliy references when the Project is loaded into

And the "Hnit Path" is mainly used for building time, when
the IDE will build the project, it’ll locate the assemblies which is
required to link through the "Hint Path".
Anyway, they’re all internally
used by the VS.NET IDE, and is possibly to change in sequential version and
they have nothing to do with the .NET framework CLR’s runtime assembly

For .net framework CLR’s runtime assembly locating, it’ll follow a well
defined steps, generally, it’ll check GAC (if strong-named) first, then,
codebase settting , and private path probing. Here is a MSDN reference
which describing the .NET framework’s runtime assembly locating:

#How the Runtime Locates Assemblies

In addition, if you have interests, I’d recommend you the following books:

Don Box’s "Essential dotNet"
and Steven Pratschner’s "Customzing the Microsoft .NET Framework CLR"

which has detailed description on .NET runtime’s assembly binding and

SQL: Difference between ODBC and OLEDB

From: http://www.maxi-pedia.com/What+is+the+difference+between+ODBC+and+OLEDB

What is the difference between ODBC and OLEDB?

First, let us take a look at ODBC.


ODBC stands for Open Data Base Connectivity, which is a connection method to data sources.

When connecting a tool or application to a database, a data source, also called a Database Source Name (DSN), using an SQL driver or other driver if connecting to other database type, needs to be set up. Then, the application is connected to the database using this DSN.

DSN is a data structure used to describe a connection to a database. A DSN will take the form of a protocol: subprotocol: host: port:. Those are the parameters required to completely specify the connection. The exact format of the DSN will vary depending on your programming language.

ODBC is the method of connectivity that encompases the DNS. Most database systems support ODBC.


OLEDB stands for Object Linking and Embedding Database. It is an application programming interface designed by Microsoft for accessing different types of data stores in a uniform manner.

It is a newer and improved successor to ODBC.

OLEDB is the successor to ODBC, a set of software components that allow a "front end interface" such as a graphical user interface (GUI) based on VB, C++, Access, and others to connect with a back end such as SQL Server, Oracle, DB2, mySQL, etc.

OLEDB components in many cases offer improved performance over the older ODBC.

OLEDB is a different type of data provider that came about with MS’s Universal Data Access in 1996.

OLEDB does not require a DSN.

Additional information

More information can be found at the Microsoft website:


From: http://www.dotnetspider.com/forum/23743-what-e-difference-between-OLEDB-ODBC-conc.aspx

ODBC-it is designed for connecting to relational databases. (Sql Server, Oracle etc)
However, OLE DB can access relational databases as well as nonrelational databases. (Oracle, Sql-Server, Excel, raw files, etc)

There is data in your mail servers, directory services, spreadsheets, and text files. OLE DB allows SQL Server to link to these nonrelational database systems. For instance, if you want to query, through SQL Server, the Active Directory on the domain controller, you couldn’t do this with ODBC, because it’s not a relational database. However, you could use an OLE DB provider to accomplish that.

In summary, The key difference between OLE DB and ODBC is that OLE DB can provide connection to data stored in non-relational format.

From: http://stackoverflow.com/questions/103167/what-is-the-difference-between-ole-db-and-odbc-data-sources

According to this book (excellent diagram here), he says precisely what MOZILLA said.

(directly from page 7 of that book)

· ODBC provides access only to relational databases

· OLE DB provides the following features

· Access to data regardless of its format or location

· Full access to ODBC data sources and ODBC drivers

So it would seem that OLE DB interacts with SQL-based datasources THRU the ODBC driver layer.

I’m not 100% sure this image is correct. The two connections I’m not certain about are ADO.NET thru ADO C-api, and OLE DB thru ODBC to SQL-based data source (because in this diagram the author doesn’t put OLE DB’s access thru ODBC, which I believe is a mistake).