Hi Katerina, thanks for the thorough response.  I'll try to comment on why I think this is,in fact, a very useful and architecturally sound feature request.

As for auditing/logging, I agree with much of what yousay.  An 'AuditEntityBase' base classseems like a wonderful idea.  However, weare dealing with a legacy database as well as other client applications that we need topeacefully coexist with.  So adding 2extra columns to hundreds of tables is not something that would really go overwell.  Side note: we do have aninterface that contains ModifiedDate and ModifiedUser and do use that in the same way you suggest - but we are only able to do this because those fields already existed in our database so it was an easy one for us to'do right'.  Unfortunately, sometimes a legacy systemforces you to do things that aren't how you would do it on a brand new project

I've already digressed a bit because, as it turns out, our application uses database triggers formost of our auditing and logging.  It'svery straightforward logic that I have no problems doing in a trigger with abunch of boilerplate and unchanging SQL.  There's not a lot ofcomplicated business logic and, as a bonus, all our client applications get thatauditing/logging behavior 'for free' without having to 'reinvent the wheel'.  Also, updates to our database through'not-so-official-methods' (e.g. ad-hoc SQL scripts) end up triggering the sameaudit/logging logic so there is no way to bypass it.

As you might have guessed, I'm not requesting this feature in orderto perform logging or auditing.  Nearlyall of my use cases involve times where I need to know the auto-generatedprimary key of an entity and use it to update the database in the sametransaction as the original save.  The specific cases are abit domain-specific, but I’ll try to give some simplified examples.  Imagine this kind of scenario:

Imagine we have a table that contains 'email deliveryrequests'.  The table functions as aqueue where our application can add requests and some other system picks upthose requests and services them by sending emails.  So maybe after a new Customer is saved, wewant add a new entity such as the following: new EmailDeliveryRequest{Subject="NewCustomer Created", To="Bob", Body="There is a new customer with ID 123 that youshould do something with"}.  How would we do this with DevForce...let's look at the existing options:

1. We add the new EmailDeliveryRequest entity before the save because we don’t knowwhat the customer's ID will be.  
2. This isn't the kind of thing that we'd want to put in a trigger because the logic can getcomplicated (some new customers go to Bob, other ones go to Sally, etc.).  And I very much dislike having non-trivial logic hidden away in SQL where I can't see it, test it, etc.
3. We most certainly want the request to becreated within the same transaction so we don’t have to worry about a Customergetting saved correctly but then something going wrong when we try to save theEmailDeliveryRequest.  So trying to make two SaveChanges calls from the client is not an option.
4. We can't just make an association in our model and have the temporary-id fixup logic take care of it since the ID ends up stuffed in a string so DevForce/EF would have no chance at figuring it out.
5. Write a stored procedure where we pass Subject/To/Body and it adds a row for us.  Then we can call this procedure as part of the save process within the transaction.  This ends up being the only viable solution so we go with it.  But then we have a bunch of stored procedures that exist solely to do something embarrassingly simple like add 3 values to a table somewhere.  Not very fun.  A related solution would be to drop down to low-level ADO.NET, raw SQL or something like that to do the INSERTs.  Again, not a very fun thing to do.