I know that I can use the following code to enumerate all SQL Server instances on network:
SqlDataSourceEnumerator instance = SqlDataSourceEnumerator.Instance;
DataTable table = instance.GetDataSources();
But I was wondering if there was a way of doing this for Oracle Instances as well. Oracle's ODP.NET (Oracle.DataAccess.Client) supports DataSourceEnuerator, apparently System.Data.OracleClient doesn't though. However the DataSourceEnumerator only enumerates the entries that are found in the local TNSNames.ora file.
What you're seeing is due to the fundamental difference in how SQL Server and Oracle databases announce themselves. SQL Server (at least 2000 and 2005) use the SQL Browser Service to advertise databases available on the network. Oracle, on the other hand, requires you to explicitly enumerate instances available using TNS entries.
This is an instance of When in Rome, where Oracle is attempting to follow the API. Unfortunately, without custom code you won't be able to replicate the SQL Server behavior.
Related
Apparently, using AttachDbFilename and user instance in your connection string is a bad way to connect to a DB. I'm using SQL server express on my local machine and it all seems to work fine. But what's the proper way to connect to SQL server then?
Thanks for your explanation.
Using User Instance means that SQL Server is creating a special copy of that database file for use by your program. If you have two different programs using that same connection string, they get two entirely different copies of the database. This leads to a lot of confusion, as people will test updating data with their program, then connect to a different copy of their database in Management Studio, and complain that their update isn't working. This sends them through a flawed series of wild goose chase steps trying to troubleshoot the wrong problem.
This article goes into more depth about how to use this feature, but heed the very first note: the User Instance feature has been deprecated. In SQL Server 2012, the preferred alternatives are (in this order, IMHO):
Create or attach your database to a real instance of SQL Server. Your connection string will then just need to specify the instance name, the database name, and credentials. There will be no mixup as Management Studio, Visual Studio and your program(s) will all be connecting to a single copy of the database.
Use a container for local development. Here's a great starter video by Anna Hoffman and Anthony Nocentino, and I have some other resources here, here, and here. If you're on an M1 Mac, you won't be able to use a full-blown SQL Server instance, but you can use Azure SQL Edge if you can get by with most SQL Server functionality (the omissions are enumerated here).
Use SqlLocalDb for local development. I believe I pointed you to this article yesterday: "Getting Started with SQL Server 2012 Express LocalDB."
Use SQL Server Compact. I like this option the least because the functionality and syntax is not the same - so it's not necessarily going to provide you with all the functionality you're ultimately going to want to deploy. Compact Edition is also deprecated, so there's that.
Of course if you are using a version < SQL Server 2012, SqlLocalDb is not an option - so you should be creating a real database and using that consistently. I only mention the Compact option for completeness - I think that can be almost as bad an idea as using AttachDbFileName.
EDIT: I've blogged about this here:
Bad Habits : Using AttachDBFileName
In case someone had the problem.
When attaching the database with a connection string containing AttachDBFile
with SQLEXPRESS, I noticed this connection was exclusive to the ASP.NET application that was using the database. The connection did block the access to all other processes on the file level when made with System.Data.SqlClient as provider.
In order to assure the connection to be shareable with other processes
instead use DataBase to specify the database name in your connection string
Example or connection string :
Data Source=.\SQLEXPRESS;DataBase=PlaCliGen;User ID=XXX;password=ZZZ; Connect Timeout=30
,where PlaCliGen is the name (or logical name) by which SQLEXPRESS server knows the database.
By connecting to the data base with AttachDBFile giving the path to the .mdf file
(namely : replacing DataBase = PlacliGen by AttachDBFile = c:\vs\placligen\app_data\placligen.mdf) the File was connected exclusively and no other process could connect to the database.
Apparently, using AttachDbFilename and user instance in your connection string is a bad way to connect to a DB. I'm using SQL server express on my local machine and it all seems to work fine. But what's the proper way to connect to SQL server then?
Thanks for your explanation.
Using User Instance means that SQL Server is creating a special copy of that database file for use by your program. If you have two different programs using that same connection string, they get two entirely different copies of the database. This leads to a lot of confusion, as people will test updating data with their program, then connect to a different copy of their database in Management Studio, and complain that their update isn't working. This sends them through a flawed series of wild goose chase steps trying to troubleshoot the wrong problem.
This article goes into more depth about how to use this feature, but heed the very first note: the User Instance feature has been deprecated. In SQL Server 2012, the preferred alternatives are (in this order, IMHO):
Create or attach your database to a real instance of SQL Server. Your connection string will then just need to specify the instance name, the database name, and credentials. There will be no mixup as Management Studio, Visual Studio and your program(s) will all be connecting to a single copy of the database.
Use a container for local development. Here's a great starter video by Anna Hoffman and Anthony Nocentino, and I have some other resources here, here, and here. If you're on an M1 Mac, you won't be able to use a full-blown SQL Server instance, but you can use Azure SQL Edge if you can get by with most SQL Server functionality (the omissions are enumerated here).
Use SqlLocalDb for local development. I believe I pointed you to this article yesterday: "Getting Started with SQL Server 2012 Express LocalDB."
Use SQL Server Compact. I like this option the least because the functionality and syntax is not the same - so it's not necessarily going to provide you with all the functionality you're ultimately going to want to deploy. Compact Edition is also deprecated, so there's that.
Of course if you are using a version < SQL Server 2012, SqlLocalDb is not an option - so you should be creating a real database and using that consistently. I only mention the Compact option for completeness - I think that can be almost as bad an idea as using AttachDbFileName.
EDIT: I've blogged about this here:
Bad Habits : Using AttachDBFileName
In case someone had the problem.
When attaching the database with a connection string containing AttachDBFile
with SQLEXPRESS, I noticed this connection was exclusive to the ASP.NET application that was using the database. The connection did block the access to all other processes on the file level when made with System.Data.SqlClient as provider.
In order to assure the connection to be shareable with other processes
instead use DataBase to specify the database name in your connection string
Example or connection string :
Data Source=.\SQLEXPRESS;DataBase=PlaCliGen;User ID=XXX;password=ZZZ; Connect Timeout=30
,where PlaCliGen is the name (or logical name) by which SQLEXPRESS server knows the database.
By connecting to the data base with AttachDBFile giving the path to the .mdf file
(namely : replacing DataBase = PlacliGen by AttachDBFile = c:\vs\placligen\app_data\placligen.mdf) the File was connected exclusively and no other process could connect to the database.
I'm developing a WPF application, which connects MS SQL2008 database remotely.
The app communicates with the database by Linq-to-SQL. pretty handy.
However, because of the slow database server, I'm trying to use local database caching.
"VS2010 > Add Item > Local database cache" wizard could be a solution, but it uses DataSet and SQL Compact(*.sdf).
I found Linq-To-SQL cannot generate classes from the SQL COMPACT edition!
(when I drag tables, error pops up and says 'unsupported data provider')
So, is there any solution to use Linq-to-SQL with local database cache?
or is there any database sync method played with Linq-to-SQL?
If you still want to go the sql compact way, Lightspeed is a linq-to-sql provider that supports a variety of data-sources. it includes mssql compact.
http://www.mindscapehq.com/products/lightspeed
The free version is sufficient for most projects, with an 8 model/class limit.
Ive used it as a linq provider for MySql and Sql Compact before and it's been great.
You can see everything it supports and how it compares to other existing systems like it here:
http://www.mindscapehq.com/products/lightspeed/comparing-lightspeed
the Local Database Cache Wizard only supports SQL Ce on the client side. if you have SQL Express/SQL Server on the client side, you can use Sync Framework still.
see following samples/tutorials using Sync Framework:
Synchronizing SQL Server and SQL Express
Database Sync:SQL Server and SQL Express 2-Tier
nevermind if it mentions SQLExpress, the SQLSyncProvider referenced in the code should work against SQL Express,SQL Server, and SQL Azure
Hey guys I'm new to C# and I'm a little confused on the fields that need to be provided in the connection string while using oledb to connect to my sql server 2008 database, particularly one of them.
The "Provider" field is really giving me problems, partially because I'm not really sure what it does. I have tried two different Provider strings and they both come back with the same error:
The "System.Data.SqlClient provider is not registered on the local machine
Or
The "Microsoft.Jet.OLEDB.4.0" provider is not registered on the local machine
Can someone tell me what this means? Also, my task requires me to not use any addition installations, is there a provider that is default?
Thanks
The Microsoft Jet Engine is the database engine used in Microsoft Access. The error simply means that the required Access version is not installed and thus, your application cannot open the OLEDB driver.
Generally, you should probably just use the System.Data.SqlClient.SqlConnection class instead of the System.Data.OleDb.OleDbConnection class to connect to your SQL Server 2008 database. The connection string should be much simpler.
We want to allow access to our custom back end data store by pretending to be an ODBC server such as Access or SQL Server. In this way, anyone with those ODBC drivers could connect and send us queries (from anything from asp.net to Excel) which we will resolve on the back end and return a result set.
I have the ability to parse SQL and return result set based on a dynamic sql query. What I don't know is how to pretend to be an ODBC or OLEDB server. I don't even care which server we mimic as long as it's a common one that has drivers that ship with windows.
I have searched but could not find a basic implementation that implements authentication and ExecuteQuery() methods. Does such a .net project exist?
You could implement an ADO.NET data provider?
see http://msdn.microsoft.com/en-us/library/a6cd7c08.aspx
The System.Data.Sqlite project is an excellent example of how to build an ADO.NET data provider for an arbitrary data store.