>Keeping it simple seems best to me.

Always good advice. <g>

>The code that the designer generates for a Typed DataSet is quite extensive ... you're re-inventing the wheel? Why?

Good point. I was playing with the idea because on the surface there appears to be a lot of overhead in the designer code. (May just be an illusion.)

I'll have to play with the WriteXmlSchema and see what it generates.

With 2008 about to come out I am probably better off using the XSD method.

>>Also I am considering putting my business logic into my datasets, do you see any inherent problems with that? (Basically making the Business Object a subclassed dataset.)
>
>That depends. I don't see anything wrong with keeping a limited amount of business logic in the DataSet class (I wouldn't sub-class anymore, not with the advent of 2.0's partial classes). I say "limited amount" because, IMHO, you don't want to put too much of that in the DataSet itself. Take, for instance, the example I mentioned above of using the same DataSet amongst different development teams. Different teams might have different usage needs for the same DataSet, predicating different business rules. I'd limit any biz logic to stuff you need to keep the data clean ... minimal stuff like that. That's just my opinion of course. <g>

That's makes good sense. This is my first time using Business Objects, my VFP code base was developed prior to the concept, so I am still wrapping my head around how to implement them.

Thanks Again!

John

*****

>>I already have a data access layer written that is designed to be provider independent, and is a fully separate layer from my datasets. (I modeled it after the code you gave me. Which was great BTW!)
>
>Glad I could give you some good ideas for that. =0)
>
>>Having gotten into this a ways I am now convinced that I need to write code to help generate and maintain my datasets for me.
>
>Keeping it simple seems best to me. We initially had something very simple (what I mentioned previously that simply used a Stored Proc to generate an .xsd). Plus, very simple code for generating basic stored procs for any database table (you know, just generating basic get/put/delete stored procs). We used that simple utility for 4-5 years and it worked great for our small team. But then we got more developers in the company involved, and the need arose to be able to share datasets amongst different development teams. So we had one of our developers come up with something a bit more complicated ... and he got a bit carried away. It's a bit cumbersome to use now, unfortunately. I prefer the good ol' days. <g>
>
>>I am wondering if I even need to use the XSDs or... since my code will basically replace the built in designer, if I should just go straight to generating datasets in code. Any advantage in creating the XSDs?
>
>The code that the designer generates for a Typed DataSet is quite extensive ... you're re-inventing the wheel? Why?
>
>>Also I am considering putting my business logic into my datasets, do you see any inherent problems with that? (Basically making the Business Object a subclassed dataset.)
>
>That depends. I don't see anything wrong with keeping a limited amount of business logic in the DataSet class (I wouldn't sub-class anymore, not with the advent of 2.0's partial classes). I say "limited amount" because, IMHO, you don't want to put too much of that in the DataSet itself. Take, for instance, the example I mentioned above of using the same DataSet amongst different development teams. Different teams might have different usage needs for the same DataSet, predicating different business rules. I'd limit any biz logic to stuff you need to keep the data clean ... minimal stuff like that. That's just my opinion of course. <g>
>
>~~Bonnie
>