I'm connecting my application to a SQL Server 2008 database.
What is the difference between the following providers: System.Data.SqlClient provider and SQLNCLI10.1 if there is any?
Which one should be used to connect to a SQL Server database and why?
Thanks,
System.Data.SqlClient is a managed provider. SQLNCLI is an OleDB provider. Which means they are as distinct as it gets. Nothing in common, really, besides the fact that they're both connecting to SQL Server. But using completely different and unrelated technologies. In your applications you should use SqlCLient when writing managed code (.Net). OleDB is for native applications (C++).
I would guess that the only difference is that the latter specifies a specific version (which may or may not be present as the code moves from server to server or the box is touched by software updates etc). The former just says "get the current version" and in my mind is safer.
Back in the classic ASP days I vaguely remember that specifying the most recent version explicitly (e.g. Provider=SQLOLEDB.1) seemed to work better than just Provider=SQLOLEDB but I don't recall the specifics. I do remember that some web hosts didn't have up to date stuff, and the explicit request for a more recent version would fail there with something similar to "provider not found."
Related
I have a MacBook Pro and want to learn more about sql, I understand I cannot run sql from a Mac, what should I install VMware, linux, windows 10? Can someone walk me through this
SQL is just domain specific language (primarily) for relational databases. What you need to decide is what RDBMS, which in turn implements SQL, you would like to use.[1] Standalone implementations like SQLite definitely run on the Mac (many of Apple's own applications like Mail use it as their database.) For the more complex client/server RDBMS systems (i.e. Oracle, SQL Server, MySQL/MariaDB, etc.) you will at least need to install client-side drivers (often in the form of ODBC, JDBC or native drivers) and then either connect to an existing[1] database or install your own database server.
Since it sounds like you're just getting started, I'd highly recommend starting with a standalone database such as SQLite which you should be able to get to by opening a terminal window and typing 'sqlite3' at the prompt. This will allow you to jump right in and focus on learning SQL itself rather than dealing with getting a full-blown client/server database server up and running. (move on to that later if you find it needed/interesting/useful to you)
[1] unless you need to use an existing database, at work for example, in which case you'll need to find out the various details about the server and database in order to connect to it. In this case, you'll need to find a point of contact (often a DBA) to provide this information.
I have been using MS Access databases via DAO for many years, but feel that I ought to embrace newer techniques.
My main application runs on end user PCs (no server) and uses a shared database that is created and updated on-the-fly. When the application is first run it detects the absence of a database and creates a new empty one.
Any local user running the application is allowed to add or update records in this shared database. We have a couple of other shared databases, that contain templates, regional information, etc., but these are not updated directly by the application.
Updates of the application are released from time to time and each new update checks the main database version and if necessary executes code to bring the database up to the latest specification. This may involve the creation or deletion of tables and/or columns. New copies of the template databases are also included as part of the update.
Our users are not required to be computer-literate and should not need to run any sort of database management software beyond those facilities provided by the application.
It all works very nicely with DAO/Access, but I'm struggling to find how to do it with SQL Express. The databases seem to be squirrelled away in locations that are user-specific and database creation and update seems at best awkward to do by program code alone.
I came across some references "Xcopy deployment" that looks like it could be promising, but there seem to be references to "user instances" that sound suspiciously like something that's not shared. I'd appreciate advice from anyone who has done it.
It sounds to me like you haven't fully absorbed the fundamental difference between the Access Database Engine (ACE/Jet) and SQL Server:
When your users launch your Access application it connects to the Access Database Engine that has been installed on their machine. Their copy of ACE/Jet opens the shared database file (.accdb or .mdb) in the network folder. The various instances of ACE/Jet work together to manage concurrent updates, record locking, and so on. This is sometimes called a "peer-to-peer" or "shared-file" database architecture.
With an application that uses a SQL Server back-end, the copies of your application on each user's machine connect over the network to the same instance of SQL Server (that's why it's called "SQL Server"), and that instance of SQL Server manipulates the database (which is stored on its local hard drive) on behalf of all of the clients. This is called "client-server" or "server-based" database architecture.
Note that for a multi-user database you do not install SQL Server on the client machines, you only install the SQL Server Client components (OleDb and ODBC drivers). SQL Server itself is only installed in one place: the machine that will act as the SQL... Server.
re: "database creation and update seems at best awkward to do by program code alone" -- Not at all, it's just "different". Once again, you pass all of your commands to the SQL Server and it takes care of creating the actual database files. For example, once you've connected to the SQL Server if you tell it to
CREATE DATABASE NewDatabase
it will create the database files (NewDatabase.mdf and NewDatabase_log.LDF) in whatever local folder it uses to store such things, which is usually something like
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA
on the server machine.
Note that your application never accesses those files directly. In fact it almost certainly cannot do so, and indeed your application does not even care where those files reside or what they are called. Your app simply talks to the SQL Server (e.g. ServerName\SQLEXPRESS) and the server takes care of the details.
Just to update on my progress. Inspired by suggestions here and this article on code project:
http://www.codeproject.com/Articles/63147/Handling-database-connections-more-easily,
I've created a wrapper for the ADO.NET methods that looks quite similar to the DAO stuff that I am familiar with.
I have a class that I can use just like a DAO Database. It wraps ADO methods like ExecuteReader, ExecuteNonQuery, etc. with overloads that can accept a SQL parameter. This allows me to directly replace DAO Recordsets with readers, OpenRecordset with ExecuteReader and Execute with ExecuteNonQuery.
Each method obtains and releases the connection from its parent class instance. These in turn open or close the underlying connection as required depending on the transaction state, if any. So a connection is held open for method calls that are part of a transaction, but closed immediately for a single call.
This has greatly simplified the migration of my program since much of the donkey work can be done by a simple "find and replace". The remaining issues are then relatively easy to find and sort out.
Thanks, once again to Gord and Maxwell for your advice.
This answer is too long to right down... but go to Microsoft page, there they explain how to make it: http://office.microsoft.com/en-us/access-help/move-access-data-to-a-sql-server-database-by-using-the-upsizing-wizard-HA010275537.aspx
I hope this help you!!
How to read data, submit queries from vb application to a remote machine running sql server.
Please note: I have created a complete functional version of a stock control system with the database residing in the local machine. I just need the basic concept of interacting with remote databases that's all. Do we have to use sockets to read/send data ?
All you need to do is change your connection string to the remote db server and make sure that the server is actually listening. (Link assumes 2005 but 2k, 2k8+ config will be similar and easily Googled for...) You definitely DO NOT have to write special code for this.
Check out http://connectionstrings.com/ for a handy reference for the different types of connection strings in different situations.
Are we talk about .NET version of VB or old fashioned VB 6?
In .NET version of VB (VB.NET) you can use OLEDB Data adapter, ODBC Data Adapter or native .NET Data adapter depends on your needs.
See MSDN documentation enter link description here
In VB6 version, you can use ADO, OLEDB or ODBC. See documentation here: http://msdn.microsoft.com/en-us/library/aa968814(v=vs.85).aspx
I don;t recommendate to connect your application via socket by yourself because this is really bloody coding.
I am trying to migrate from Access Database to SQL server database. Do I need to make changes (for saving, reading, deleting etc. data) to my code as well?
I understand I need to change connection but what about code?
Thanks
Furqan
For the most part, Access SQL Queries are very similar to SQL Server Queries. Therefore, unless you're using Access-specific constructs such as Val, CInt, etc in your queries, you can safely migrate to SQL Server.
It is recommended though, that you thoroughly test the program after migration lest you run into 'strange' errors.
I'm sure the conversion will require some time and troubleshooting. For one, Access through version 2007 uses VBA for the back-end code and SQL Server's programming is quite different from VBA. Developer's transitioning from Visual Basic 6 (very similar to VBA) to VB.NET ran into quite a few challenges.
Also, keep in mind that SQL Server is best used as the back-end storage engine. The user interface is typically written in a .NET language using Visual Studio. SQL Server (at least through 2005 -- I haven't used 2008) doesn't have user interface components like a File Open dialog box.
Imports System.Data.OleDb
Public Class Log
Private mConnectionString As String = "Provider=OraOLEDB.Oracle;Data Source=(DESCRIPTION=(CID=GTU_APP)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx)(PORT=1521)))(CONNECT_DATA=(SID=xxx)(SERVER=DEDICATED)));User Id=xxx;Password=xxx;"
Dim ds As New DataSet
Dim da As New OleDbDataAdapter
Dim dr As DataRow
Dim Connection As New OleDbConnection(mConnectionString)
Dim Command As OleDbCommand
goes on...
That's the code, and it works great on our development machines. We all have the Oracle providers installed on our machines. Now I tried using this code in an app on another machine that does not have the Oracle software installed and it doesn't work.
Now I know I can install the Oracle providers on these other machines and it will work. Problem with that is A) there are many of them and B) I'd have to go through our IT department and it would take six months for them to do it. So my question is, can I connect to this Oracle database from a machine without the Oracle providers installed? I thought Microsoft had it's own Oracle provider but it doesn't show up under System.Data. The .NET version is 3.5 if that helps. Any ideas?
I've had fairly good luck with the Oracle Instant Client and ODP.NET, which is pretty much a straight XCOPY deploy (if you don't need ODBC).
IIRC, you do need to modify the PATH environment variable, but that's relatively painless - especially compared to the hoops Oracle used to make you jump through.
The problem is actually you started a project without discussing the infrastructure needs with your company's IT/DBA team. This is not a technical problem but a process problem.
That being said here is a possible solution (although I haven't used personally).
http://devart.com/dotconnect/oracle/
I'm pretty certain you have to install the Oracle provider in order for this to work. OleDb can easily connect to SQL Server and Access and so on, but only because these providers come pre-installed in Windows.
I think your only option (other than installing the Oracle provider on every machine) is to create a SQL Server "front" database that includes pass-through tables to each Oracle table you need, and then get your data from SQL Server instead of Oracle.
Actually, another option would be to have your client applications get their data from an intermediate web service instead of connecting directly to the database, but this would probably entail a major re-write.
Would it be possible to find and include the Oracle DLLs with your app instead of installing them?