Get back value after save with update trigger

Hi,

Recently, I have added a trigger to column in one of my table. This column is of type 'DateTime' and a trigger update automatically the date with the function GetDate() of SQL Server.

With that, I have a TimeStamp column human readable of the last time the row has beed updated.

When I update the row with a lightspeed entity and call the savechanges of unitofwork, the entity doen't have immediatly the new date assign by the trigger; I must close my unitOfWork, create another one and retreive again my entity with this new unitOfWork to have the new date.

Is there other way to get back the new date? I know that you have a cache system but how it works in this case?

Here is an example of the trigger:

ALTER TRIGGER [dbo].[Trigger_Tag_TimeStamp_WhenInsertRowUpdateTimeStamp] ON [dbo].[Tag] FOR INSERT AS BEGIN        

UPDATE Tag SET TimeStamp=GETDATE()        

WHERE Id IN (SELECT Id FROM inserted) END

And here is an example of the code that use the entity:

         Using unitOfWork
            tag = unitOfWork.Tags.First

            tag.Nom = "Modification"

            unitOfWork.SaveChanges()

            Here I want to know the new date generated by the trigger

            MsgBox(tag.TimeStamp)

         End Using

Sorry, this isn't possible at the moment.  Your approach of reloading in a new unit of work is currently the only way of getting updated values for an entity which is already loaded.  I've logged a feature request for this -- thanks for the suggestion!

Incidentally, in the specific case of capturing the save time, LightSpeed can do this for you (see the Track Update Time option in the designer).  If you use this option then the entity time stamp *will* be available after the save.  The down side is that this is a client-side timestamp and therefore may not be guaranteed if your client PCs have unreliable clocks.  (By default it also has time zone issues, but you can avoid these by setting the AutoTimestampMode to Utc.)  May not do what you need, and I realise it doesn't solve the more general problem, but just thought I'd mention it!

Thank you very much for taking the time to submit a new feature. It does not matter if I must reload the entity with another UnitOfWork because I think that why "LightSpeed" is so "Speedy" is because you don't do thing that makes code overhead if is not absolutly necessary.

I understand that if the entity automatically recharged, you have to query the database and in my cases, 99% of the time, I'm not worry about data generated by the server when I commit the entity.

The case where I need it is that i'm currently writing integration tests to test a replication system and I use a lot of TimeStamp to replicate two databases and it's critical to test somes TimeStamp value.

I cannot use your system of tracking because some of my queries is in pure SQL and I don't want to remember each time that I write a query to update the TimeStamp because again the TimeStamp is very critical. With trigger, i'm on the way.

I know you must be thinking that the feature that you have record will be nice if is not systematically when you save but a property for each entity in the model to define if when entity is save, a fetch is made to bring back the new data because of overhead again.

Last week, you have buy a licence of Telerik for some components and we have OpenAccess and I have check for the feature of this post and it work correctly but the architecture of LightSpeed (Pattern like UnitOfWork, Entity, ValueObject ect...) is so beautiful compare to OpenAccess that I would not change a hundred years for another orm that LightSpeed.

Thank you again to answer my questions. For now I'll make UnitOfWork, UnitOfWork and UnitOfWork so small and the only result is has on my architecture is to improve it.

Sorry for the last post, I write "you have buy a licence of Telerik". I meat "we have bought a licence of Telerik".

:)

Hi,

I'm interested in this issue of retrieving a DateModified value inserted by a Trigger back to a single UOW calling code.

Has Ivan's workaround had a little work done on it? (eg a method to query the server-side time and keep it sync'ed...)

I'm looking for a simple method to prevent users overwriting each others info. In UPDATE statements having a WHERE DateModified = @DateModified is a easy way... if the affected record count is zero, another user has edited the record.

Is NeoSynergix.'s the best workaround to date?

Cheers,

If all you want is to prevent users overwriting each others' changes, turn on Optimistic Concurrency Checking.  This adds a LockVersion field to the entity which will be checked during updates.

In the more general case of capturing changes made by update triggers, sorry, no, nothing has changed.

Thanks Ivan, I'll read up on this "Optimistic Concurrency Checking". In reality 2 calls to get the trigger value back isn't such a big deal.

Cheers,