What About the Data Environment?

[Previous] [Next]

Visual Basic 6.0 introduced the Data Environment to simplify data access development. It makes many chores so much simpler, and in particular it allows you to use much less code to access your data. Instead of writing code, you use mouse pointing and drag-and-drop operations to declare ADO Connection and Command objects.

We love the Data Environment, but we don't use it in our MTS applications. We might, of course, miss something, doing things we shouldn't or not doing things we should, but in our opinion the Data Environment and MTS don't mix well. If your application deals mostly with read-only data, you might get away with using MTS and the Data Environment together, but as soon as you set the transactional attribute to require a transaction or require a new transaction for a component that depends on the Data Environment, things will probably go wrong for you. Setting a component to support transactions seems to be OK, just as long as that component isn't called from a component set to require transactions; if such a component is called from a transactional component, you'll have trouble on your hands. So, as we said, MTS and the Data Environment don't get along very well.

We hope this situation will change in time. Remember that the Data Environment is a version 1.0 kind of thing. Microsoft usually gets most things right after a version or two of any kind of technology or application. But we doubt that the Data Environment will play an important role for MTS or COM+ developers. We suspect it's created on the assumption that components using it will stay connected to the database, whereas you as an MTS/COM+ developer want to stay connected as little as possible.