This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello. In my database model (SqlServer 2005) there is a table with a timestamp column. I used such column to know when a row has changed (in my LS-previous concurrency checking). The problem is that LS tries to update this column, and SQLServer timestamp columns are not updatable. These columns must not be included in the INSERT and UPDATE sql commands. I'am porting my application to use LightSpeed and when porting is complete I could remove that column but in the meantime I need it. Thank you. |
|
|
Just exclude that field from your model: then LightSpeed will not attempt to load or save it. |
|
|
Hello Ivan. I need that column to know if a row has changed, so I cant remove from the model. To resolve the problem, now I use optimistic concurrency (LockVersion field), so the field is never updated, but I think that you must exclude that kind of fields in INSERT and UPDATES. |
|
|
Hello Enrique, This is probably too late to be helpful for the present port, but I just found out that there is a way of excluding fields from INSERTs and UPDATEs in LightSpeed: make the field readonly. Note that you have to put readonly on the backing field, not the property, and that the designer does not support this (so you would have to set Generation to None and do it through the partial class). The data is still read from the database, but is not included in saves. Let me know if you need more info. |
|
|
Hello Ivan.
Thank you. It works for me. I dont use the designer so its ok. What is the 'Generation'?
Ivan, another question: I need desperately to update a modified entity but I dont want to call uow.SaveChanges() because the other changes may be undone later: I need to save an isolated entity. Investigating I found a solution (a very simple solution): I create a new UOW, attach the modified entity, save changes of that UOW, dispose it, and reattach the entity back to the original UOW. It seems that works (very well) but is it dangerous to do it? Thank you. |
|
|
Your attach-based solution should be okay. Moving entities between UOWs can cause problems with relationships, and we have had a report of a bug if you subsequently null out an association of the re-attached entity. But if your entity is isolated then it should be fine. Re "Generation": First off, "Generation" is a designer thing -- it is NOT relevant to users like you who do not use the designer, so don't worry about it! But if you're interested... the "Generation" setting is the escape hatch from the designer. It allows you to prevent the designer from generating code for a property (or generate only a field but no property). This allows you to create your own implementation in a partial class. At first glance this sounds crazy: if you're going to write your own code for it, why bother adding it to the designer? The answer is database synchronisation: by including it in the designer you can have us add it to the database schema, include it in migrations, etc. (Plus of course visualisation.) |
|