Walter,

We use Typed DataSets exclusively in our .NET app. One should know beforehand what result-set they are expecting to get back from the database. We never build SQL statements on the fly. IMHO, all data access should be through Stored Procs (we use a SQL Server backend).

~~Bonnie


>Hi kevin,
>
>>I have one thing to add to this. How about database access ?? It seems more or less going through a same mechanism where you have to interface between fields of which you don't know the exact type and the strong typed variables in the language. How does the compiler handle that, since it cannot determine the type of a field at compile time ??
>
>
>>Typed datasets that correspond to your data might be one answer. The compiler can enforce data types, so long as you reference the field as an object (e.g. MyDataSet.MyTable[0].MyField).
>
>Thanks, I've seen this before (I think I've read that message somewhere in the past, or was it a MSDN article ?). But of course in practise things might be different. When doing database access your never be sure what gets returned by a SQL SELECT * statement or a stored procedure. The compiler has of course then has now way of knowing of what type a certain field is. So what happens if a field is added or removed to the resultset. Does the program blow up or has it a more intelligent way of resolving the issue ?? Typed datasets of course can be a very valid answer in a lot of cases, though it might require a bit more maintenance. But in case you're building up a SQL statement on the fly where the field list can be dynamic, typed datasets seem to be a less attractive option IMO.
>
>Walter,