Here is an except from the book "SQL Server 2000 Weekend Crash Course"
OSQL-A command-line utility used to connect to SQL Server and execute
Transact-SQL statements (covered in Session 8). The results of the executed
commands will be displayed in the DOS console window. OSQL uses the ODBC
(Open Database Connectivity) interface to connect to SQL Server.
ISQL-Uses the DB-Library interface to communicate with SQL Server. It is a
database-specific interface and is not portable. In addition to this, ISQL
does not support many of the new features in Microsoft SQL Server 2000.
Another Excerpt: In SQL Server 2000, all utilities except isql use the ODBC
API and the SQL Server ODBC Driver.
The implication being that ODBC is the way forward. I read another
newsgroup article that said the recommend way forward is in fact OLE DB and
not ODBC. I have come from Sybase where I have been using Ct-Lib almost
exclusively and not needed anything like OLE DB. What advantage does it
offer over ODBC? Is it genuinly easy to get up and running in a matter of
hours, or am I going to spend a week trying to understand it, and another
week getting it to function. Does any existing coding have to change?
Whats my upside/downside for switching to OLE-DB?
Thanks
What should drive this decision is your choice of client application.
ODBC is no longer cutting-edge, having been superceded by OLE DB
(ADO). This is what you'd use with a VB6 or older COM client. However,
if you are working in any of the .NET technologies, then you'll want
to use ADO.NET (coding in either C# or VB.NET) using the SqlClient
provider.
--Mary
On Wed, 19 May 2004 20:20:14 +0200, "Grant Reid"
<grant.reid@.telefonica(dot)net> wrote:
>Here is an except from the book "SQL Server 2000 Weekend Crash Course"
>OSQL-A command-line utility used to connect to SQL Server and execute
>Transact-SQL statements (covered in Session 8). The results of the executed
>commands will be displayed in the DOS console window. OSQL uses the ODBC
>(Open Database Connectivity) interface to connect to SQL Server.
>ISQL-Uses the DB-Library interface to communicate with SQL Server. It is a
>database-specific interface and is not portable. In addition to this, ISQL
>does not support many of the new features in Microsoft SQL Server 2000.
>Another Excerpt: In SQL Server 2000, all utilities except isql use the ODBC
>API and the SQL Server ODBC Driver.
>The implication being that ODBC is the way forward. I read another
>newsgroup article that said the recommend way forward is in fact OLE DB and
>not ODBC. I have come from Sybase where I have been using Ct-Lib almost
>exclusively and not needed anything like OLE DB. What advantage does it
>offer over ODBC? Is it genuinly easy to get up and running in a matter of
>hours, or am I going to spend a week trying to understand it, and another
>week getting it to function. Does any existing coding have to change?
>Whats my upside/downside for switching to OLE-DB?
>Thanks
>
Showing posts with label book. Show all posts
Showing posts with label book. Show all posts
Monday, March 12, 2012
ODBC vs OLE DB ??
Here is an except from the book "SQL Server 2000 Weekend Crash Course"
OSQL-A command-line utility used to connect to SQL Server and execute
Transact-SQL statements (covered in Session 8). The results of the executed
commands will be displayed in the DOS console window. OSQL uses the ODBC
(Open Database Connectivity) interface to connect to SQL Server.
ISQL-Uses the DB-Library interface to communicate with SQL Server. It is a
database-specific interface and is not portable. In addition to this, ISQL
does not support many of the new features in Microsoft SQL Server 2000.
Another Excerpt: In SQL Server 2000, all utilities except isql use the ODBC
API and the SQL Server ODBC Driver.
The implication being that ODBC is the way forward. I read another
newsgroup article that said the recommend way forward is in fact OLE DB and
not ODBC. I have come from Sybase where I have been using Ct-Lib almost
exclusively and not needed anything like OLE DB. What advantage does it
offer over ODBC? Is it genuinly easy to get up and running in a matter of
hours, or am I going to spend a week trying to understand it, and another
week getting it to function. Does any existing coding have to change?
Whats my upside/downside for switching to OLE-DB?
ThanksWhat should drive this decision is your choice of client application.
ODBC is no longer cutting-edge, having been superceded by OLE DB
(ADO). This is what you'd use with a VB6 or older COM client. However,
if you are working in any of the .NET technologies, then you'll want
to use ADO.NET (coding in either C# or VB.NET) using the SqlClient
provider.
--Mary
On Wed, 19 May 2004 20:20:14 +0200, "Grant Reid"
<grant.reid@.telefonica(dot)net> wrote:
>Here is an except from the book "SQL Server 2000 Weekend Crash Course"
>OSQL-A command-line utility used to connect to SQL Server and execute
>Transact-SQL statements (covered in Session 8). The results of the executed
>commands will be displayed in the DOS console window. OSQL uses the ODBC
>(Open Database Connectivity) interface to connect to SQL Server.
>ISQL-Uses the DB-Library interface to communicate with SQL Server. It is a
>database-specific interface and is not portable. In addition to this, ISQL
>does not support many of the new features in Microsoft SQL Server 2000.
>Another Excerpt: In SQL Server 2000, all utilities except isql use the ODBC
>API and the SQL Server ODBC Driver.
>The implication being that ODBC is the way forward. I read another
>newsgroup article that said the recommend way forward is in fact OLE DB and
>not ODBC. I have come from Sybase where I have been using Ct-Lib almost
>exclusively and not needed anything like OLE DB. What advantage does it
>offer over ODBC? Is it genuinly easy to get up and running in a matter of
>hours, or am I going to spend a week trying to understand it, and another
>week getting it to function. Does any existing coding have to change?
>Whats my upside/downside for switching to OLE-DB?
>Thanks
>
OSQL-A command-line utility used to connect to SQL Server and execute
Transact-SQL statements (covered in Session 8). The results of the executed
commands will be displayed in the DOS console window. OSQL uses the ODBC
(Open Database Connectivity) interface to connect to SQL Server.
ISQL-Uses the DB-Library interface to communicate with SQL Server. It is a
database-specific interface and is not portable. In addition to this, ISQL
does not support many of the new features in Microsoft SQL Server 2000.
Another Excerpt: In SQL Server 2000, all utilities except isql use the ODBC
API and the SQL Server ODBC Driver.
The implication being that ODBC is the way forward. I read another
newsgroup article that said the recommend way forward is in fact OLE DB and
not ODBC. I have come from Sybase where I have been using Ct-Lib almost
exclusively and not needed anything like OLE DB. What advantage does it
offer over ODBC? Is it genuinly easy to get up and running in a matter of
hours, or am I going to spend a week trying to understand it, and another
week getting it to function. Does any existing coding have to change?
Whats my upside/downside for switching to OLE-DB?
ThanksWhat should drive this decision is your choice of client application.
ODBC is no longer cutting-edge, having been superceded by OLE DB
(ADO). This is what you'd use with a VB6 or older COM client. However,
if you are working in any of the .NET technologies, then you'll want
to use ADO.NET (coding in either C# or VB.NET) using the SqlClient
provider.
--Mary
On Wed, 19 May 2004 20:20:14 +0200, "Grant Reid"
<grant.reid@.telefonica(dot)net> wrote:
>Here is an except from the book "SQL Server 2000 Weekend Crash Course"
>OSQL-A command-line utility used to connect to SQL Server and execute
>Transact-SQL statements (covered in Session 8). The results of the executed
>commands will be displayed in the DOS console window. OSQL uses the ODBC
>(Open Database Connectivity) interface to connect to SQL Server.
>ISQL-Uses the DB-Library interface to communicate with SQL Server. It is a
>database-specific interface and is not portable. In addition to this, ISQL
>does not support many of the new features in Microsoft SQL Server 2000.
>Another Excerpt: In SQL Server 2000, all utilities except isql use the ODBC
>API and the SQL Server ODBC Driver.
>The implication being that ODBC is the way forward. I read another
>newsgroup article that said the recommend way forward is in fact OLE DB and
>not ODBC. I have come from Sybase where I have been using Ct-Lib almost
>exclusively and not needed anything like OLE DB. What advantage does it
>offer over ODBC? Is it genuinly easy to get up and running in a matter of
>hours, or am I going to spend a week trying to understand it, and another
>week getting it to function. Does any existing coding have to change?
>Whats my upside/downside for switching to OLE-DB?
>Thanks
>
Friday, March 9, 2012
ODBC tracing! No Info
Hi I know I should be able to find this out myself , but both book I have don't seem to know and the online helps isn't much better.
I want to find out if ODBC tracing is on or off, and if it is on I want to be able to turn it off.
How can I do this? I just can't find any Info on it!
Thanks Ed
P.S. If their was a Icon for simpleton, I would use it!ODBC Tracing? I'm not sure what you are talking about. You can get server and connection information with these commands:
sp_configure
SQLGetConnectAttr
SQLSetConnectAttr
blindman|||Originally posted by blindman
ODBC Tracing? I'm not sure what you are talking about. You can get server and connection information with these commands:
sp_configure
SQLGetConnectAttr
SQLSetConnectAttr
blindman
My orginal problem was that EM runs really slowely when looking a propeties. So I searched through the existing threads to try and find out what the problem and one of the suggestion was that I may have ODBC tracing turned on and that could be slowing down the system, but I could not find a way see if ODBC tracing was on or off.
I thought it was on a setting withine the database , now figured it out by talking to the other in the office, sorry, thanks anyway!|||odbc tracing is in admin tools/datasource configuration. it comes very handy by allowing to see what actual statements are issued by the driver manager. poobah probably never used it :)|||Nope. I haven't. My expertise is in database design, transact sql programming, and query optimization. I know a fair amount about database tuning and administration, but in general I leave those posts to others to answer.
Like nixies, I couldn't find anything in Books Online referencing this configuration. Is it strictly middle-tier or interface resident?
blindman|||all sql server client tools are using odbc driver manager one way or the other. below is a sample set of entries from the log file if you turn tracing on in your data sources tracing tab:
SQL Server Ente 7b4-794 ENTER SQLAllocHandle
SQLSMALLINT 1 <SQL_HANDLE_ENV>
SQLHANDLE 00000000
SQLHANDLE * 01B471D4
SQL Server Ente 7b4-794 EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS)
SQLSMALLINT 1 <SQL_HANDLE_ENV>
SQLHANDLE 00000000
SQLHANDLE * 0x01B471D4 ( 0x01a31540)
SQL Server Ente 7b4-794 ENTER SQLSetEnvAttr
SQLHENV 01A31540
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003
SQLINTEGER -5
if tracing is turned on the performance of that workstation deteriorates. as an example i turned it on and opened em and expanded a server (in a sense connected to it). within a minute after it i turned tracing off. the resulting file size was 472K. mind you i didn't do anything other than what i described, - connected to the server and nothing else.|||Now I see. So its a workstation setting, not a server setting.
Thanks
blindman|||not necessarily, you can do the same thing on the server.
I want to find out if ODBC tracing is on or off, and if it is on I want to be able to turn it off.
How can I do this? I just can't find any Info on it!
Thanks Ed
P.S. If their was a Icon for simpleton, I would use it!ODBC Tracing? I'm not sure what you are talking about. You can get server and connection information with these commands:
sp_configure
SQLGetConnectAttr
SQLSetConnectAttr
blindman|||Originally posted by blindman
ODBC Tracing? I'm not sure what you are talking about. You can get server and connection information with these commands:
sp_configure
SQLGetConnectAttr
SQLSetConnectAttr
blindman
My orginal problem was that EM runs really slowely when looking a propeties. So I searched through the existing threads to try and find out what the problem and one of the suggestion was that I may have ODBC tracing turned on and that could be slowing down the system, but I could not find a way see if ODBC tracing was on or off.
I thought it was on a setting withine the database , now figured it out by talking to the other in the office, sorry, thanks anyway!|||odbc tracing is in admin tools/datasource configuration. it comes very handy by allowing to see what actual statements are issued by the driver manager. poobah probably never used it :)|||Nope. I haven't. My expertise is in database design, transact sql programming, and query optimization. I know a fair amount about database tuning and administration, but in general I leave those posts to others to answer.
Like nixies, I couldn't find anything in Books Online referencing this configuration. Is it strictly middle-tier or interface resident?
blindman|||all sql server client tools are using odbc driver manager one way or the other. below is a sample set of entries from the log file if you turn tracing on in your data sources tracing tab:
SQL Server Ente 7b4-794 ENTER SQLAllocHandle
SQLSMALLINT 1 <SQL_HANDLE_ENV>
SQLHANDLE 00000000
SQLHANDLE * 01B471D4
SQL Server Ente 7b4-794 EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS)
SQLSMALLINT 1 <SQL_HANDLE_ENV>
SQLHANDLE 00000000
SQLHANDLE * 0x01B471D4 ( 0x01a31540)
SQL Server Ente 7b4-794 ENTER SQLSetEnvAttr
SQLHENV 01A31540
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003
SQLINTEGER -5
if tracing is turned on the performance of that workstation deteriorates. as an example i turned it on and opened em and expanded a server (in a sense connected to it). within a minute after it i turned tracing off. the resulting file size was 472K. mind you i didn't do anything other than what i described, - connected to the server and nothing else.|||Now I see. So its a workstation setting, not a server setting.
Thanks
blindman|||not necessarily, you can do the same thing on the server.
Subscribe to:
Posts (Atom)