Visual Studio itself is an IDE, an Interactive Development Environment - not a tool for interacting with databases. However, there are .NET CLR (Common Language Runtime) libraries for programmatic DB access.

I recommend, however, that you start with the asking the developers to create product hooks for you to use to interact with the database. This is likely to be safer than interacting with it directly with your tests. I'm pretty decent with programmatic DB access and still prefer to do it, when testing, through product hooks that are disabled in production. Product hooks definitely will get wrapped in tests and verified for consistent, well-understood behavior (unless the team is very lax). Test libraries, on the other hand, tend to get less care and are more likely to have bugs and unexpected side effects. Also, it simplifies how to manage authentication, as the product already authenticates for DB access.

Barring that, see how the developers and the product code interface with the databases. They may already have some great tools that simplify DB access compared to the libraries you would normally use, or they may have tools that enforce certain rules around how you access the DB that you need to use.

If that fails, you probably want to look at the database access classes in the CLR: MSDN's ADO .NET with SQL Server page is a good place to start. The MSDN documentation on LINQ to SQL, in particular, will contain the bulk of what you need to know.

If you go this route and are not familiar with database access code, I strongly recommend getting both test design reviews and code reviews from the product developers. There are often security implications around how the tests handle database authentication, and database interactions can have messy and long-lasting impacts on test environments.

Visual Studio itself is an IDE, an Integrated Development Environment - not a tool for interacting with databases. However, there are .NET CLR (Common Language Runtime) libraries for programmatic DB access.

I recommend, however, that you start with the asking the developers to create product hooks for you to use to interact with the database. This is likely to be safer than interacting with it directly with your tests. I'm pretty decent with programmatic DB access and still prefer to do it, when testing, through product hooks that are disabled in production. Product hooks definitely will get wrapped in tests and verified for consistent, well-understood behavior (unless the team is very lax). Test libraries, on the other hand, tend to get less care and are more likely to have bugs and unexpected side effects. Also, it simplifies how to manage authentication, as the product already authenticates for DB access.

Barring that, see how the developers and the product code interface with the databases. They may already have some great tools that simplify DB access compared to the libraries you would normally use, or they may have tools that enforce certain rules around how you access the DB that you need to use.

If that fails, you probably want to look at the database access classes in the CLR: MSDN's ADO .NET with SQL Server page is a good place to start. The MSDN documentation on LINQ to SQL, in particular, will contain the bulk of what you need to know.

If you go this route and are not familiar with database access code, I strongly recommend getting both test design reviews and code reviews from the product developers. There are often security implications around how the tests handle database authentication, and database interactions can have messy and long-lasting impacts on test environments.