Q&As from William Vaughn's Feb. 5 ADO.NET Webinar

When using a sqlclient conection where you have to supply the datasource name, uid and password. what would be the best way to obtain this information without hard coding it into your connect string. I am assuming that if you use NT authentication with the SQL server then you do not have to add the uid and pwd to the connect string but what about the datasource name?

Answered: When using the SqlClient .NET Data Provider, there are a few choices–not as many as in ADOc, but still several alternatives. Ideally, you should use Integrated Security=SSPI instead of a user-unique UID/PWD (to avoid flooding the connection pool). As far as the server is concerned (Data Source), this can be extracted from a registry entry or file, but in most cases, this should remain fixed—and let the cluster manager handle the routing. There is no concept of a "Datasource" as in the ODBC sense in ADO.NET SqlClient. If anything changes in the ConnectionString, connection pooling will be affected—a new pool is created for each variation of the ConnectionString/Transaction.

If it is a web form grid, can we make it real time? I am wondering about locking issues.

Answered: Remember that ADO.NET uses a disconnected/disjoint data access model. The data shown in a grid is as current as the latest query's resultset. ADO.NET also uses optimistic concurrency so rows on the server do not remain locked while a copy is maintained in the middle or client tier. This also means you'll have to be prepared for concurrency issues once updates are made.

If we are at the end of the file how do we use Dr.NextResult with erroring out?

Answered: The DataReader is designed to deal with multiple resultsets. Dr.NextResult steps to the next set of results (if there are any). This should work if there are multiple rowsets returned or if the next result has no rowset, then you might have to trap an exception and step to the next. I'll have a sample of this approach in an upcoming article.

Will VBA be still supporting other softwares like Microsoft Great Plains or it will be updated to VBA .NET?

Answered: That's a (good) question for Microsoft. I expect that VBA will be adapted in time to the new technology.

Are we seeing a return to DataBinding with ADO.NET verus non Databinding with ADOc?

Answered: Yes, Databinding has been reborn. It's far more sophisticated in .NET and works much better. You aren't held back by the limitations of the technology.

Can you define the table relationships within the XML schema?

Answered: AFAIK you can.

Do the references to 'works with SQL 7 and 2000' also apply to MSDE?

Answered: Of course. MSDE is SQL Server.

Do any of the items on the "Not (Yet) Slide at the Beginning" really concern you from using this new technology at present?

Answered: Not really. We'll quickly find work-arounds for these issues and Microsoft will fill in the gaps ASAP.