>Hi Linda. Please don't take anything personally. It's just very frustrating on my end when I'm forced to use a product that we did not / will not have training on and the "Jump Start" example is very elementary.
>
>Thanks.

Hi Robert,

I would view that as an opportunity. Take a lead in learning it inside and out and be the "Go To" guy in your company for the product. Once you figure things out, this is a great tool because it is so flexible and yet so extendable. The code is all there. I agree the jumpstarts are not very in depth and I am considering a project to help with that. However all the code is there so lots of opportunity to figure out the inside workings. If there is anything I can help with, let me know.

As far as auto incrementing PK's, I avoid them for many reasons. One being I tend to move data around or merge it with other data. I really need GUID's as my primary key so I don't worry about conflicts. Second, I don't like not having control over and immediate access to the primary key when the record is new. With this framework, you can easily set the default value of a New Entity PK to Guid.NewGuid() and it is immediately available to use with children and will easily be added to children that are registered with the parent. Waiting till after a save to get the primary key of a parent back is just not my idea of useful or reliable. Plus add to that and what happens with disconnected adds of records? Say you are saving to a serialized entity and will add it to the table when the database is available again or a user comes back onto the network. Just my opinion however not everyone shares it.
Good luck
Timothy