When designing a new Crystal Report you have to create a new database connection. I have selected OLE DB (ADO) as the 'driver' as it made more sense than DAO,RDO or the other options for my requirements.
I need to execute an SQL Server 2005/2008 stored procedure on a remote server and show the results in Crystal Reports on a .NET client.
Selecting OLE DB, presents me with further options to select the correct provider, some of which are:
Microsoft OLEDB provider for ODBC drivers
Microsoft OLEDB provider for SQL Server
SQL Native Client
SQL Server Native Client 10.0
Which on is the best to use?
I don't want to use the ODBC drivers, for various disadvantages (setting up ODBC definitions and maybe slower).
Not sure how the OLEDB provider for SQL Server compares with the native client
The native client forced me to run the native client setup on each desktop. It also seems that there is different version for each version of SQL Server.
Initially I thought the native client is the logical choice for compatibility and performance but deployment seems to be an issue (unless I am doing something wrong)
What is the best connection driver/provider combination to use here?
I would go with the Microsoft OLEDB provider for SQL Server. If you use the native client, you will need to distribute it with your applications.
This article talks about the native client in detail: http://blog.flex2sql.com/index.php/2009/02/how-and-when-to-use-sql-server-native-client/
Related
I am using CDatabase in VC2008 to connect to SQL Server via ODBC.
I want to use a common connection string that can work for SQL Sever 2005 and all higher versions.
I check https://www.connectionstrings.com/microsoft-sql-server-odbc-driver/ and see there are many different kinds of connection strings.
Whether I should use:
Driver={SQL Server};Server=myServerAddress;Database=myDataBase;Uid=myUsername;
or
Driver={SQL Native Client};Server=myServerAddress;Database=myDataBase;
Uid=myUsername;Pwd=myPassword;
Pwd=myPassword;
Update:
Based on my test, using Driver={SQL Server} or Driver={SQL Server Native Client 10.0} can both connect to SQL Server 2008. I guess the former will works for all SQL Server versions, but the latter will only works for SQL Server 2008. Please confirm my guess.
Both driver will connect to Sql Server.But purpose of both drivers are different.
Driver={SQL Server} :
It is called Windows Data Access Components (WDAC).
It do not support new feature of Sql server 2005+ like xml data type,Multiple active result sets (MARS), user-defined data types (UDT), query notifications etc.
It support only Read Committed transaction isolation.
Driver={SQL Native Client}
This driver is suitable for application that need to take advantage of new feature of Sql server 2005+.
It support both Read Committed transaction and snapshot transaction isolation level.
System.Data.SQLClient
SQLClient is optimize for .NET and database Sql server 2000+.
It give maximum performance.
So if your application is new or existing then use SQL Native Client.It can access all feature of connected version of Sql server 2005,2008 etc.
ODBC :Use ODBC when application is connected to multiple database or it is expected that database may change.DAL code is written in such a manner it will work for any database.
Suggested Reading
Common Connection : I don't think there can be any common connection.Suppose in my system SQL server native client 10 is install then I know that I cannot connect to Sql server 2016 + .SQL server native client 10 will work for Sql Server 2016 and below.
Of course by programming we can make dynamic connection string which will accept driver as parameter etc.
To connect to higher version ,s I will hv to upgrade my driver and do minor change in connection string.Or if you don't want to touch code then Use DSN.
Yes I forgot, Driver={SQL Server Native Client} it can connect to Sql Srver 2005 only.if you try to connect to higher version then it will throw error.
I have a legacy system at one of our locations in the US. We currently have a reporting system using SQL Server Report Builder on a central server running SQL Server 2014 using the native client SQL 11.0. I need to build a report using two different remote systems. I have setup linked servers before, but the current issue is that I am trying to setup a linked server to a 2000 server. When I try to make the connection to it it returns an error that native client 11 cannot communicate with SQL Server 2000. I have not found any reliable work around for this, and am trying to see if there is a resolution or solution that can be used.
I was also wondering if maybe a possibility is to create a ODBC connection the SQL server. Then create a linked server to the ODBC, in return that is older version.
ODBC to SQL Server 2000
SQL client 11 to ODBC
Is this possible, or a very poor way to handle this? Thanks in advance!
I'm not sure how to interpret this quote from the MSDN documentation. Is the native client deprecated?
There will be no more updates to the ODBC driver in SQL Server Native Client. The successor to the ODBC driver in SQL Server Native Client, which is called the Microsoft ODBC Driver 11 for SQL Server on Windows, is installed with SQL Server 2014.
The OLE DB Provider in SQL Server Native Client was last updated in SQL Server 2012 Native Client. Developers who wish to use an OLE DB provider to connect to the latest version of SQL Server must use the OLE DB provider that shipped in SQL Server 2012 Native Client.
I also found this statement on msdn.
Microsoft has announced the deprecation of the SQL Server Native Client OLE DB provider, and that SQL Server 2012 is the last version of SQL Server to support the provider. This article provides guidance for converting SQL Server or SQL Azure applications that use OLE DB to the ODBC API.
Connection string samples for the different suggestions is also helpful :)
These statements imply that the older drivers will no longer receive updates, and instead will be replaced by newer drivers. You should test your VB6 app using the new Microsoft ODBC Driver 11 for SQL Server on Windows. OLE DB and ODBC are independent technologies, so the quotes you found do not relate to each other. The first quote applies to your situation. My suspicion is that it will simply work. ODBC drivers are agnostic to the language the calling applications are written in, so you'll be fine.
I believe all of this reflects Microsoft's move away from desktop Windows as the primary client platform as they move their server products (e.g. SQL Server) into Azure.
The Linux and Apple ecosystems never adopted COM, and so stayed away from OLE DB since they lacked the necessary infrastructure. The same remains true for younger OSs such as Android and Chrome OS.
On the other hand while ODBC is a cruder technology it has been widely adopted outside of Windows, spawning thin wrappers and work-alikes such as JDBC drivers.
By moving away from Windows technologies such as OLE DB Microsoft is in a better position, both to support other client OSs and to move SQL Server to another OS running in Azure since they see a "Windowless" future ahead.
...
As far as VB6 development goes in the interim, I'd stick with the SQL Server 2012 Native Client OLE DB provider just as Microsoft suggests. But you might want to begin looking elsewhere for client development tools since VB6 and even VB.Net appear to be nearing the end of the road. Soon there might not be a lot left of .Net at all aside from C# supporting the bits and pieces in .Net Core.
I am pretty confused with the plethora of OLEDB providers found in creating a connection to a database in SSIS 2008 R2.
I would much appreciate if you could tell me what the following providers stand for and when is best to use them:
.Net Providers for OleDB
Microsoft OLE DB Provider for SQL Server
SQL Server Native Client 10.0
Native OLE DB
Microsoft OLE DB Provider for SQL Server
SQL Server Native Client 10.0
I am pretty unsure which provider to use out of these if I want to create an OLE DB connection to the database in question. Additionally, I am confused why the same type of provider appears both in .Net and Native.
Here's some more detailed information about the main two connections (OLE DB and ADO.NET). It seems to me that ADO.NET is better in the sense that it should work more universally in different environments.
You really don't have to worry too much about which one to use, select the Native one (SQLNCLI) and it'll work fine out of the box.
I am a Crystal Reports developer and I have always been working with Oracle database and this is my first time with SQL Server.
This is what I have been desperately searching for.
From my local PC, I want to connect to a SQL Server database which is on a database server.
I am aware that I need a 'SQL Server Native Client'. And I am also aware that I need to use 'sql server management studio' so that I can view the tables and writes queries instead of using a tool like TOAD.
My questions are:
Can I use 'Microsoft SQL Server Management Studio Express' from my local PC to connect to a SQL Server 2005 Database in a database server?
If I install 'Microsoft SQL Server Management Studio Express' do I still need to install a 'SQL Server Native Client'?
Thanks,
rivi
Can I use 'Microsoft SQL Server Management Studio Express' from my local PC to connect to a SQL SERVER 2005 Database in a database server?
Yes.
If I install 'Microsoft SQL Server Management Studio Express' do I still need to install a 'SQL Server Native Client'?
If you want to connect to the database from your application you will need it installed. It should be installed as part of the SSMS install.
Answer 1:
SQL Server Management Studio can be used to manage either local or remote SQL database server.
If you installed SQL Server Express, the default instance will be SQLExpress. To connect it locally using Windows Credential, just type .\SQLExpress or yourmachinename\SQLExpress in the server name textbox.
If you host the SQL Server on a remote server, you must use the credential given by the authority hosting your SQL Server. It is easy, ask your admin for the details.
Answer 2:
See this for the details
I copy and paste the important notes from the link above here:
When deciding whether to use SQL Server Native Client as the data access technology of your application, you should consider several factors.
For new applications, if you're using a managed programming language such as Microsoft Visual C# or Visual Basic, and you need to access the new features in SQL Server, you should use the .NET Framework Data Provider for SQL Server, which is part of the .NET Framework.
If you are developing a COM-based application and need to access the new features introduced in SQL Server, you should use SQL Server Native Client. If you don't need access to the new features of SQL Server, you can continue to use Microsoft Data Access Components (MDAC).
For existing OLE DB and ODBC applications, the primary issue is whether you need to access the new features of SQL Server. If you have a mature application that does not need the new features of SQL Server, you can continue to use MDAC. But if you do need to access those new features, such as the new xml Data Type, you should use SQL Server Native Client.
Both SQL Server Native Client and MDAC support read committed transaction isolation using row versioning, but only SQL Server Native Client supports snapshot transaction isolation. (In programming terms, read commited transaction isolation with row versioning is the same as Read-Committed transaction.) For more information, see Choosing Row Versioning-based Isolation Levels.
For information about the differences between SQL Server Native Client and MDAC, see Updating an Application to SQL Server Native Client from MDAC.