>Rick,
>
>Yeah, I use DataAdapter.Fill() also ... but I don't see where constraints are brought down automatically. Doesn't happen for me at all ... not PK, FK, NULL ... nothing. The only thing that I can think of is that we do *not* use the CommandBuilder ... maybe you do? I have no idea what kind of extra stuff that might do (we use SP's for all data access). Also, are you .Fill()ing a plain old DataSet (DataSet ds = new DataSet()) , or one that you've already pre-defined (MyDataSet ds = new MyDataSet())? If you have a pre-defined DataSet then maybe you're setting up some constraints before-hand that the .Fill() respects.

Nope command builder is not used for reading data only for updates. But it's bringing down restraints like Null and Pk requirements. If I add dupes for PKs the DataRow will throw an exception...

Maybe you're using a special schema exclsion option with MissingSchemaAction? I use whateer the default is...

Funny thing is I had to look that up - I can't remember since it's buried in my bus object code and I haven't written raw data access code in a long while <g>...

+++ Rick ---

>
>We're using Typed DataSets, but that shouldn't make any difference either.
>
>~~Bonnie
>
>
>
>>>>>How do you actually do that? Kill all the constraints? They come down by default don't they?<
>>>
>>>No, not that I know of. Maybe it depends on how you've created your DataSets?
>>
>>Uhm, how are you? <g> DataAdapter.Fill() would be the way I do it along with a plain jane command object.
>>
>>This will bring down primary key info and some of the constraints such as NULL requirements...
>>
>>+++ Rick ---
>>
>>>
>>>
>>>
>>>
>>>>>FWIW, we don't use any of the DataSet FK constraints or PK's at all. All FK constraints are enforced in the database and our DataAccess methods make sure things are updated in the correct order. That way we're not running into this issue at all.
>>>>
>>>>How do you actually do that? Kill all the constraints? They come down by default don't they?
>>>>
>>>>+++ Rick ---
>>>>
>>>>>
>>>>>Just another way of doing things, but I understand that you like to have the database do very little. Damned if you do and damned if you don't ... <g>
>>>>>
>>>>>~~Bonnie
>>>>>
>>>>>>>A High/Low PK generation scheme would allow you to generate valid PKs on the client. See: http://fox.wikis.com/wc.dll?Wiki~HighLowKeyGeneration~SoftwareEng
>>>>>>
>>>>>>I've done this in the past and I use something like this in true online offline applications, but it requires more discipline in setting up the ranges than I (or my clients Admins) usually have <g>... it works, but it's another one that feels like a such a hack.
>>>>>>
>>>>>>>As far as the other constraints go, this is one of my pet peeves on using DataSets to marshall data. There isn't enough meta-data. The lack of meta-data causes code to be written in the application and presentation tiers that, in effect, duplicates the meta-data. In a form that is much less maintainable.
>>>>>>
>>>>>>Well, the problem the way I see it is that it's sort of half assed. Some of it is there and fires, but some of it doesn't. OTOH, I understand that it can't all be there. In that case though I feel that it would be much better if there were no constraints rules etc at all as opposed to having them there incomplete, because now we have to work around the things that are there to make things that aren't work. <g>
>>>>>>
>>>>>>I tend to write all of my bus and validation rules in the bus object layer and have the database do very little. Basically the only constraints I set on the server are related to making the data access mechainsmis work.
>>>>>>
>>>>>>>There is loads of information about a set of data, even beyond what is in the database schema, that I would like to attach to a DataSet. The client could then use this information to generically drive the presentation.
>>>>>>
>>>>>>>I suppose it might be possible to subclass the DataSet and the data adpaters to provide this additional metadata. But then again, it might not. <s>
>>>>>>
>>>>>>Well I think you can get all that data but there's overhead in that. ANd somethings like autoincrement values certainly will never work on the client without some sort of server connection, so we wuold never achieve full client independence in the first place.
>>>>>>
>>>>>>It's frustrating though and complex conceptually to constantly have to reinvent this type of thing with every new data access technology that comes along. Hence my attempt at trying to leave as much as possible to rules and processing on the client. That way the least amount of database dependency is required.