>>>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.