Hi Matt,

>It seems like most time that I would do a join like this it is because of the way the data is normalized and that the "related" columns that I pull in are not ones that you would allow the user to directly modify.

That may be the case like the example you gave. If however you were editing an order you most likely would want to be able to change the Shipper or Employee that is connected. It is all in what you need to do like you said.

I am glad you are getting it. I also came from Foxpro so I understand. Things are very different and at times seem to be more difficult in .net although I have to say as time goes on it gets easier when you find the shortcuts and grasp the concepts.

In another post I noticed the comment about cumbersome to create the properties, but when you find the macro substitution of prop (prp in mere mortals.) you find it is all done for you.
Good luck
Tim

>
>Being totally new to .NET and MM (from a VFP background), when faced with things like this, I like to understand all possible ways, the pros and cons, and why and how it works so that I am at least partially educated and informed before I get too far along in my app design. I plan to spend all of 2008 simply playing around with certain parts of the UI design and data architecture, and then start my converting my VFP app to .NET in 2009. I've already been at if for 3 mohths and still only have 5 BO's and 1 form that I have built. I only have a few hours a day to tinker with it, but I have learned a ton, even though I have very little code to show for it.
>
>For UI, I am studying WinForms right now, but plan to learn the basics of WPF UI design also, then choose which one I will commit to for the long haul.
>
>
>
>
>>Hi Matt,
>>
>>>Wow!!! That never ocurred to me. That is cool... I've gotta make sure Tim reads this.
>>>
>>>So, what you recommend between this method vs. having a JobItems BO and Parts BO with a Releationship to pull the PartDescription into the grid?
>>>
>>>
>>
>>I amn following this thread for sure. I should have mentioned that option but didn't think about it. I would suppose there are times to do it either way depending on the situation. Relating the Biz Objs would give you the benefit of updating. If you look at the way the jump start is done, the Shipper field that is in the order is put on the form with a combobox allowing the user to change the shipper on the order. It displays the shipper name but updates the order with the shipper_Id. you wouldn't do this as easily with the view or proc method. However for just a list or report of somekind, it might make sense to do it with a view.
>>Take care
>>Tim
>>
>>>
>>>
>>>
>>>>Matt,
>>>>
>>>>>So, I need to understand how the JobItem Entity would handle the PartDescription column since it is not present in the Entity model that was generated from the Business Layer Generator. Since that field (the PartDescription) is not in the JobItems table, I was not able to pick it when generating the JobItems BO and Entity.
>>>>
>>>>You can generate entity objects from stored procedures (and views) in addition to tables. You can regen the entity from the stored procedure and it will include the PartDescription property
>>>>
>>>>Best Regards,

Timothy Bryan