DataObjects for .NET fully supports virtual mode in distributed 3-tier applications. See Application Configurations for the description of DataObjects for .NET support of distributed 3-tier applications. To create a 3-tier application in DataObjects for .NET you do not need to write any additional code. It is just a matter of changing a property and deploying your data library on a server. Likewise, you do not need any special adjustments or coding to make virtual mode work in a 3-tier application. DataObjects for .NET virtual mode is always 3-tier-ready.

DataObjects for .NET does not maintain a live database connection on the server for the lifetime of a virtual table view on a client. The server uses the connection only to serve client requests for data, at which point it fetched a limited amount of rows (a segment), sends the data to the client and forgets all about this client request, disposes of the query result and closes the database connection (due to OLE DB connection pool optimization, the connection may remain open for some time to allow its effective reuse in subsequent requests). So, DataObjects for .NET uses a stateless, scalable server technology, the same as ADO.NET, both in regular mode (DataAccessMode = Static) and in virtual mode.

Combining its innovative virtual mode and 3-tier technologies, DataObjects for .NET makes creating sophisticated, fully scalable Web-based distributed 3-tier applications a matter of point-and-click, as easy as creating a simple desktop application always used to be in Visual Basic. In fact, the developer of an application can be totally unaware of all these concepts and work as in classic client-server (or even desktop) environment. DataObjects for .NET makes it possible to take such application and turn it into a distributed one by a simple change of a few property settings. This is the real scalability of an application development framework.

Without full understanding of the trade-off between scalability and large data sets, a skeptic, when critiquing DataObjects for .NET virtual mode, can say: "OK, but that is yesterday's technology. For this type of virtual mode you need a permanent live database connection on the server for each user, so it is necessarily unscalable, it is classic client-server (2-tier) as opposed to the latest and greatest disconnected mode, which is distributed, Web-based, 3-tier, and so on and so forth". This argument is wrong and is a common misconception. These are two entirely different things:

1. One can have a live connection on the server for each user, as in classic client-server (non-scalable, bad) as opposed to a stateless server that connects on demand, as in ADO.NET (scalable, good), and
2. One can have all data fetched at once, as in ADO.NET (bad) as opposed to data fetched on demand, as in virtual mode (good).

So, ADO.NET is good in (a) and bad in (b). Some people wrongly assume that being good in (a) necessarily means being bad in (b). That is a misconception, and DataObjects for .NET virtual mode proves it. There is one qualification, though: If you consider arbitrary SQL, then yes, you cannot be good in (a) and (b) simultaneously since you need a live connection. But that is only for complex SQL statements, with GROUP BY, subqueries and other advanced features that are rarely if ever used in GUI front-ends. DataObjects for .NET virtual mode does not support full SQL (it does not support SQL-based and unbound tables, see Bound, SQL-Based and Unbound Tables). It supports only common cases (bound tables). This restriction together with sophisticated caching and optimization techniques allow it to be good both in (a) and in (b).