Chapter 6. Data Access

 <  Day Day Up  >  

IN THIS CHAPTER

  • Data Access in Visual FoxPro Before Visual FoxPro 8

  • Database Containers

  • New Features in Visual FoxPro 8

  • Data Access in Visual Basic .NET

Data is the heart of a FoxPro developer's mission. We design tables and indexes, provide keys for fast data retrieval and updating, and build screens to connect our users to their treasures.

The single most important issue for FoxPro developers contemplating migrating to Visual Basic .NET is this: How hard is it to work with data? .NET has dozens of wonderful capabilities in many other areas. But by and large, we don't care. How does it do data? That's our first and most urgent question.

The answer is, as Shakespeare said of love, "not wisely but too well." It does everything we want and more; but jeez , why did they do it that way?

If I had never used FoxPro, I wouldn't be nearly so critical. But we know better than any other segment of the database community how simple data access can be. Why can't there be simple defaults that work if you don't specify anything? There are equivalents ” sort of; there are things that do a lot of work for us, but often where there was no work to do in FoxPro. And from time to time we'll get a pleasant surprise. But my overall impression as a Fox guy is frankly that it isn't supposed to be this hard . And I'm pretty sure that in a not-too- distant future it won't be.

There is a reason for some of the difference. FoxPro data access is connected ; in Visual Basic .NET, data access is disconnected . You connect, get a record, and disconnect. After making modifications, you connect, send the update, and disconnect. The fact that the "connection" is maintained is irrelevant. In your database applications, you can open a connection when the program starts up and then use that same connection until the user closes the program. That would be an expensive modus operandi . What is more commonly done is to open a connection, get some data from SQL or send an INSERT , UPDATE , or DELETE command, and immediately close the connection. (In fact, you can build an Internet data server that connects to MSDE with a single connection, and then pool calls to it, so that dozens or hundreds of users can use a single connection. Microsoft will tell you that this violates your license agreement.) The server program is connected to the SQL database, but your client program isn't.

Regardless of the nature of the disconnected access, each new method of access involves a little more work. In Visual Basic .NET, all data access methods are disconnected. That's why it's no harder to work with XML data services in .NET than it is to work with an MDB database.

FoxPro was built for connected data access, which is very simple. As soon as you build a disconnected data access strategy, all of the implications have to be dealt with. .NET, on the other hand, starts with disconnected data access, so the problems have to be dealt with immediately.

Let's look at data issues, first at Visual FoxPro, then at the Visual Basic side. We'll look at the Data Application Blocks, hastily issued after the release of Visual Studio .NET 1.1 to answer the alarmed requests for a simpler way to access data. And we'll speculate (within the bounds of a putative NDA) as to what might be coming from Redmond.

 <  Day Day Up  >  


Visual Fox Pro to Visual Basic.NET
Visual FoxPro to Visual Basic .NET
ISBN: 0672326493
EAN: 2147483647
Year: 2004
Pages: 130
Authors: Les Pinter

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net