ADO is really very flexible. There are a dozen ways to execute queries with very little code. For example, to open a connection and execute a parameter-based stored procedure can be as easy as this:
Set cn = New Connection Set rs = New Recordset cn.Open "dsn=localserver", "admin", "pw" cn.AuthorsByYearBorn 1947, 1948, rs
When you code directly with ADO, you have full control over how and when the connection is opened, closed, and the object released. Because the prompting behavior is already correct, you don't have to worry about extra data provider prompts appearing out of nowhere. You can also provide runtime UserID and password values instead of using the values passed into the DataEnvironment object at design time.
Data binding with ADO is also not as problematic as you might think. However, what's missing from the ADO data control is the capability to define a Recordset and have it automatically construct pairs of label and TextBox (or other suitable) controls mapped to the Fields in the Recordset. However, you can use the Data Environment Designer to set up this query and manually substitute the ADODC as the DataSource on all of the bound controls, assuming you clear each bound control's DataMember property first.
But there's another option if you want to set up bound controls that do more than just extract data from unrestrained SELECT * queries such as parameter-driven stored procedures. You can use the Data Object Wizard.