>>>I though if you could store all the tables and columns in an XML file, you could create datasets on-the-fly.
>
>I change the database and run a C# procedure that generates the dataset from the database.
>That works well, but it can be a pain during development when I'm changing data structures frequently.
>
>My preference would be one data dictionary - perhaps XML as you suggest - which would update the database and the dataset or business object in a one step operation.
>
>I'm not familiar with ORM's like Entity Framework, etc. but from what I've read they might do that.

Yes, EF supports this.

>>>>>"strongly type" datasets assumes that you duplicate your datadictionary in your code no?
>>>Yes, it does.
>>>
>>>>>Doesn't that increase coupling between two components (compiled code and data in the database)
>>>
>>>The same dataset can be referring to any number of different data stores.. SQL Server, VFP, MySQL, etc. so the coupling isn't symbolic, not absolute.
>>>
>>>Frankly, I wish there were away to make the coupling tighter during development. Having to regenerate the dataset every time I change the table in the database is a pain.
>>>
>>
>>Can you make the procedure of generating datasets Data Driven? For example, in my VFP project all CursorAdapters objects are generated on the fly based on the dictionary (simple DBF file). So I only need to change (add, remove, update) the value of the column or table that is changed in the dictionary. I though if you could store all the tables and columns in an XML file, you could create datasets on-the-fly. Or is it a science fiction? <g>.
>>
>>
>>>>>Strongly-type datasets do 90% of that, plus they give you Intellisense on the columns in the datatables.
>>>>
>>>>I'm frankly puzzled about this one. As much as I love (and would love) to have intellisense on everything that resides in the database, to "strongly type" datasets assumes that you duplicate your datadictionary in your code no? Doesn't that increase coupling between two components (compiled code and data in the database) that we have worked very hard to de-couple?