>Is it possible to use VFP as the datastore when using a DAC (data access component) which will be object pooled? If so, can the OLE DB provider for ODBC be used or must the OLE DB provider due out with VFP 7 be used?
I have no experience, but there are several whitepapers in the MSDN Library; two of interest
Pooling in the Microsoft Data Access Components
May 1999
By Leland Ahlbeck and Don Willits
This article discusses the benefits, features, and behavior of pooling within the context of the Microsoft® Data Access Components (MDAC) architecture, including technology-specific tips for OLE DB, Microsoft ActiveX® Data Objects (ADO), and Open Database Connectivity (ODBC) developers. (Both ODBC and OLE DB support pooling of database connections, although the exact behavior and features differ slightly.)
The article begins with a general discussion of what pooling is and the benefits it provides. Next, the following topics are discussed in detail, with "how-to" code examples:
A Dip in the Pool
Rob Macdonald
Everyone seems to know that ADO provides connection pooling, and that it must be a good idea, given all of the fuss about it. Fewer people seem confident about using it in their applications. Rob Macdonald has been exploring just how connection pooling works-both for traditional client/server and for newer n-tier/ASP applications.
There are certain givens about database connections: They're expensive to create, and they're expensive to maintain. Ever since developers have been writing programs that connect to servers, we've faced a dilemma about how to manage connections:
Should we create the connection at the beginning of a session and hold onto it for as long as possible? This way, we only have to wait once to create the connection, but it means we hold onto an expensive server resource that we probably use for less than five percent of the time we hold it.
Or do we create a new connection each time we have a server operation to perform-releasing it immediately afterwards? This is "kind" to servers, in that it keeps the number of live connections they need to maintain down to a minimum. However, it's tough on our users-they have to wait for a new connection to be established each time they need server resources. The time it takes to create a new connection should be sub-second-but all too often it isn't. And, to make matters worse, if we're executing several queries in quick succession, even sub-second probably isn't fast enough.
It's a classic "rock and a hard place" dilemma. Neither option is ideal. What we really need is something in between that doesn't require too much work on our part. When we're using a connection frequently, we want users to perceive response as virtually instantaneous, yet when server demand is light, we want server resources to be managed conservatively. This is especially true of n-tier applications where business objects or ASP code might be handling multiple users and the concept of a "session" starts to break down, but it's also true of traditional two-tier apps that have a lot of users.
Connection pooling is designed to solve this problem. With ADO, we can have a pool of connections managed on our behalf. The size of the pool is "demand-sensitive," meaning that it will be empty when nothing has happened for awhile, but that it might contain several live connections in a busy middle-tier application or associated with a Web site. When you ask for a new connection, if a pooled connection matches your requirements, it will be given to you; otherwise, a new connection will be created. When you release a connection, it will be pooled and will remain pooled until either it's reused or released from the pool because there's insufficient demand to justify keeping it open. All of this pool management is handled automatically, so programmers really don't need to think too much about it.
