Work with data in Visual Studio
Applies to: Visual Studio Visual Studio for Mac
In Visual Studio, you can create applications that connect to data in virtually any database product or service, in any format, anywhere—on a local machine, on a local area network, or in a public, private, or hybrid cloud.
The following lists show just a few of the many database and storage systems that can be used from Visual Studio. The Microsoft Azure offerings are data services that include all provisioning and administration of the underlying data store. The Azure development workload in Visual Studio 2017 enables you to work with Azure data stores directly from Visual Studio.
The following lists show just a few of the many database and storage systems that can be used from Visual Studio. The Microsoft Azure offerings are data services that include all provisioning and administration of the underlying data store. The Azure development workload in Visual Studio enables you to work with Azure data stores directly from Visual Studio.
Most of the other SQL and NoSQL database products that are listed here can be hosted on a local machine, on a local network, or in Microsoft Azure on a virtual machine. If you host the database in a Microsoft Azure virtual machine, you're responsible for managing the database itself.
- SQL Database
- Azure Cosmos DB
- Storage (blobs, tables, queues, files)
- SQL Data Warehouse
- SQL Server Stretch Database
- And more...
- SQL Server 2005-2016 (includes Express and LocalDB)
- And more...
- Apache Cassandra
- And more...
Many database vendors and third parties support Visual Studio integration by NuGet packages. You can explore the offerings on nuget.org or through the NuGet Package Manager in Visual Studio (Tools > NuGet Package Manager > Manage NuGet Packages for Solution). Other database products integrate with Visual Studio as an extension. You can browse these offerings in the Visual Studio Marketplace or by navigating to Tools > Extensions and Updates and then selecting Online in the left pane of the dialog box. For more information, see Compatible database systems for Visual Studio.
Many database vendors and third parties support Visual Studio integration by NuGet packages. You can explore the offerings on nuget.org or through the NuGet Package Manager in Visual Studio (Tools > NuGet Package Manager > Manage NuGet Packages for Solution). Other database products integrate with Visual Studio as an extension. You can browse these offerings in the Visual Studio Marketplace or by navigating to Extensions > Manage Extensions and then selecting Online in the left pane of the dialog box. For more information, see Compatible database systems for Visual Studio.
Extended support for SQL Server 2005 ended on April 12, 2016. There is no guarantee that data tools in Visual Studio 2015 and later will continue to work with SQL Server 2005. For more information, see the end-of-support announcement for SQL Server 2005.
All .NET data access, including in .NET Core, is based on ADO.NET, a set of classes that defines an interface for accessing any kind of data source, both relational and non-relational. Visual Studio has several tools and designers that work with ADO.NET to help you connect to databases, manipulate the data, and present the data to the user. The documentation in this section describes how to use those tools. You can also program directly against the ADO.NET command objects. For more information about calling the ADO.NET APIs directly, see ADO.NET.
For data-access documentation related to ASP.NET, see Working with Data on the ASP.NET site. For a tutorial on using Entity Framework with ASP.NET MVC, see Getting Started with Entity Framework 6 Code First using MVC 5.
Universal Windows Platform (UWP) apps in C# or Visual Basic can use the Microsoft Azure SDK for .NET to access Azure Storage and other Azure services. The Windows.Web.HttpClient class enables communication with any RESTful service. For more information, see How to connect to an HTTP server using Windows.Web.Http.
For data storage on the local machine, the recommended approach is to use SQLite, which runs in the same process as the app. If an object-relational mapping (ORM) layer is required, you can use Entity Framework. For more information, see Data access in the Windows Developer Center.
If you are connecting to Azure services, be sure to download the latest Azure SDK tools.
For a database to be consumable in ADO.NET, it must have a custom ADO.NET data provider or else must expose an ODBC or OLE DB interface. Microsoft provides a list of ADO.NET data providers for SQL Server products, as well as ODBC and OLE DB providers.
If you're using Visual Studio to connect to databases using OLEDB or ODBC data providers, you will need to be aware that versions of Visual Studio prior to Visual Studio 2022 are all 32-bit processes. This means some of the data tools in Visual Studio will only be able to connect to OLEDB or ODBC databases using 32-bit data providers. This includes the Microsoft Access 32-bit OLEDB data provider as well as other third-party 32-bit providers.
If you're using Visual Studio 2022 to connect to databases, you will need to be aware that Visual Studio 2022 is a 64-bit process. This means some of the data tools in Visual Studio will not be able to connect to OLEDB or ODBC databases using 32-bit data providers.
If you need to maintain 32-bit applications that connect to OLEDB or ODBC databases, you will still be able to build and run the application with Visual Studio 2022. However, if you need to use any of the Visual Studio Data Tools such as Server Explorer, Data Source Wizard, or the DataSet Designer, you will need to use an earlier version of Visual Studio that is still a 32-bit process. The last version of Visual Studio that was a 32-bit process was Visual Studio 2019.
If you plan on converting the project to be a 64-bit process, it’s recommended that you use the 64-bit Microsoft Access Database Engine, also called Access Connectivity Engine (ACE). Please see OLE DB Provider for Jet and ODBC driver are 32-bit versions only for more information.
In .NET, you have three choices for modeling and manipulating data in memory after you have retrieved it from a data source:
Entity Framework The preferred Microsoft ORM technology. You can use it to program against relational data as first-class .NET objects. For new applications, it should be the default first choice when a model is required. It requires custom support from the underlying ADO.NET provider.
LINQ to SQL An earlier-generation object-relational mapper. It works well for less complex scenarios but is no longer in active development.
Datasets The oldest of the three modeling technologies. It is designed primarily for rapid development of "forms over data" applications in which you are not processing huge amounts of data or performing complex queries or transformations. A DataSet object consists of DataTable and DataRow objects that logically resemble SQL database objects much more than .NET objects. For relatively simple applications based on SQL data sources, datasets might still be a good choice.
There is no requirement to use any of these technologies. In some scenarios, especially where performance is critical, you can simply use a DataReader object to read from the database and copy the values that you need into a collection object such as List<T>.
C++ applications that connect to SQL Server should use the Microsoft® ODBC Driver 13.1 for SQL Server in most cases. If the servers are linked, then OLE DB is necessary and for that you use the SQL Server Native Client. You can access other databases by using ODBC or OLE DB drivers directly. ODBC is the current standard database interface, but most database systems provide custom functionality that can't be accessed through the ODBC interface. OLE DB is a legacy COM data-access technology that is still supported but not recommended for new applications. For more information, see Data Access in Visual C++.
C++ programs that consume REST services can use the C++ REST SDK.
C++ programs that work with Microsoft Azure Storage can use the Microsoft Azure Storage Client.
Data modeling—Visual Studio does not provide an ORM layer for C++. ODB is a popular open-source ORM for C++.
Install Python support in Visual Studio to create Python applications. The Azure documentation has several tutorials on connecting to data, including the following:
- Django and SQL Database on Azure
- Django and MySQL on Azure
- Work with blobs, files, queues, and tables (Cosmo DB).
Microsoft AI platform—Provides an introduction to the Microsoft intelligent cloud, including Cortana Analytics Suite and support for Internet of Things.
Microsoft Azure Storage—Describes Azure Storage, and how to create applications by using Azure blobs, tables, queues, and files.
Azure SQL Database—Describes how to connect to Azure SQL Database, a relational database as a service.
SQL Server Data Tools—Describes the tools that simplify design, exploration, testing, and deploying of data-connected applications and databases.
ADO.NET—Describes the ADO.NET architecture and how to use the ADO.NET classes to manage application data and interact with data sources and XML.
ADO.NET Entity Framework—Describes how to create data applications that allow developers to program against a conceptual model instead of directly against a relational database.
Data in Office Solutions—Contains links to topics that explain how data works in Office solutions. This includes information about schema-oriented programming, data caching, and server-side data access.
LINQ (Language-Integrated Query)—Describes the query capabilities built into C# and Visual Basic, and the common model for querying relational databases, XML documents, datasets, and in-memory collections.
XML Tools in Visual Studio—Discusses working with XML data, debugging XSLT, .NET XML features, and the architecture of XML Query.
XML Documents and Data—Provides an overview to a comprehensive and integrated set of classes that work with XML documents and data in .NET.
Submit and view feedback for