Database Access with Visual C++.NET

• By Mark Schmidt and Richard Simon
• Oct 18, 2002
• Sample Chapter is provided courtesy of Sams

This chapter is from the book
Sams Teach Yourself Visual C++.NET in 24 Hours

If you've been using computers for a while now, you may remember the early days of the World Wide Web. When it first arrived, the Web was just a collection of images and static text. Later, the emergence of animation and sound broke up the monotony, but static text still prevailed. Then, one of the biggest technological advancements that transformed the Web from a source of information to a viable application platform was the emergence of server-side data access.

The use of data within databases has been around for a long time, but there hasn't been a shortage or slowdown of advancements in the field. The redesign of ActiveX Data Objects (ADO) within Visual Studio .NET is a testament to this fact. This redesign was so drastic that ActiveX doesn't really play a part in ADO.NET; however, the name, ActiveX Data Objects, was kept. As you will see in this hour, database access has changed substantially to keep up with the changing data-access models currently in use today.

In this hour you will learn:

• How and why database access, specifically ADO.NET, is designed

• How to connect to a DataStore and specify a command to fill a DataSet object

• How to retrieve and navigate through data within a DataSet object

• How to insert and delete data and then save the updated database

Connected vs. Disconnected Clients

When Microsoft announced its plans for .NET, it was clear Microsoft was designing a framework that would allow developers to easily implement applications that work over the Internet. Sure, there are ways to do this with the previous version of Visual Studio and subsequent Software Development Kit (SDK) downloads, but it's clear that the .NET Framework was designed with the Internet in mind. This is immediately apparent once you delve into ADO.NET.

When Active Server Pages (ASP) and other related technologies were released, developers were finally able to push large amounts of data from a database residing on a server to an end user without having to copy the entire database and run it locally. However, this also ushered in a new era of database access—the disconnected client. Although saying that a user browsing the Web is a disconnected client may sound like an oxymoron, the disconnection in this case refers to the user and the data source. In a multitiered architecture, there are generally three key pieces to an application. First is the user interface, which is rendered for the client. The second tier is the piece that assembles the data or, more technically, contains the logic that connects the user interface with the third tier. This third tier is the data source. So, what exactly does it mean when I say that a client is disconnected?

Suppose you had to construct the necessary logic to support a few simultaneous connections from clients. After you got past the code to synchronize the data, connect and disconnect clients, and transfer data, you're essentially finished. With just a few client connections, your data connections are flowing smoothly. Now, add a hundred more simultaneous connections (or a thousand or a million) and watch as the performance of your application drops substantially. By keeping all these connections open, your application will sooner or later come crashing down. This is, in essence, the connected client scenario. In the early days of data access, creating an application of such magnitude would have been extremely difficult due to the complexity involved with the database-access API functions at that time.

In the previous example, you need a data-access method that solves the performance problems associated with large numbers of simultaneous connections. One solution is to limit the number of simultaneous connections. However, as the number of clients grows, some of them may be waiting a long time. Another solution could entail transferring the entire database to the client along with the necessary logic to manipulate the data on the client machine. I think you can judge for yourself why this would be a bad idea. Another solution could be to connect with a client, give the code that houses the data-access logic a quick snapshot of the current data, and then disconnect the data connection and let the logic tier handle it from there, periodically reconnecting and disconnecting to make small changes. This is one of the methods currently implemented within ADO.NET, and it's known as a disconnected client scenario.