Limitations of Databinding
The latest version of this topic can be found at Visual Studio 2017 Documentation. Databinding is a powerful way to create data applications quickly. However, the current databinding controls architecture is inherently two tier.
Scalability
ADO data-bound controls can only access data from the ADO data control. RDO data-bound controls can only access data from the RDO RemoteData control. For RDO RemoteData control, there is no workaround but to use a two-tier architecture, which results in the database server receiving all data retrieval requests directly. To avoid directly connecting to the database server, write a provider that allows access to middle-tier business and data objects. The ADO data control connects to these objects, rather than the database server. Such middle-tier objects can be cached and managed in a transaction server such as COM+ 1.0 services.
Versioning and Distribution
When new versions of controls are released, the application will have to be tested with the new versions. If another application is installed on a user's computer, and it has a different version of the controls, the application will have to be checked. Finally, when new versions of controls are released, the new controls will have to be distributed to application users.
Drivers and Providers
Databinding is only as good as the ODBC driver or OLE DB provider you are using. Because the drivers and providers are responsible for exposing data to data controls, it is important to ensure that the driver or provider supports the functionality that you need. When you select a driver or provider, you must also ensure that your users have the driver or provider installed. This includes installing any middleware that the driver or provider requires. For example, for ODBC Oracle connectivity, the user should have installed not only an ODBC Oracle driver, but also Oracle's SQL*Net middleware. For connectivity to Oracle 7.3 servers, the Microsoft Oracle ODBC driver is recommended.
Programmability
Because ActiveX controls were designed to be black-box components, programmability is limited to a developer's access to the control's interfaces. In the databinding model in the resource editor, this is implemented through wrapper classes generated by the Insert ActiveX Control Wizard. If the wizard is unable to detect a coclass, no wrapper class is generated and there is no programmatic access.
Despite these limitations, databinding affords a way to rapidly prototype data applications using Visual C++. If speed of development is important, databinding should be considered when designing your application.