Yes, that's how Linq to SQL work. If you disable EntityTracking you cannot submit changes directly.
You should use another DataContext (with EntityTracking enabled) to submit changes. In some case you could need to take a copy of the original entity and use the Table.Attach method that takes the new and the original entity. But note that QueryCache is now (get latest svn!) disabled by default, so you could continue use the ObjectTracking if you need to. Than you will The problem you talk about QueryCache is a known issue. As stated, I'm planning to fix it. It's my 5th entry in the DbLinq todolist... BUT with QueryCacheEnabled == false, that issue should disappear. Giacomo On Sun, Jun 7, 2009 at 3:22 PM, <[email protected]> wrote: > > > > On Jun 5, 7:29 am, Giacomo Tesio <[email protected]> wrote: > > > > A difficulty I have had with DbLinq is the fact that it also acts like> > an ORM and caches queries in an attempt to optimise database access. > > > In my case I need the database to be updated and queried immediately > > > on every call and don't want any caching within DbLinq. > > > > I've not seen such optimisation in the code (a part from QueryCache), so > > what do you mean with this? > > Hi Giacomo, > > I believe my problem is with the QueryCache. If I do a query with > something dynamic like DateTime.Now in the query expression then the > value of DateTime.Now in the generated SQL will never change and will > always be the same as when the query was first made. From another post > the solution to this may be generating the query a different way but > I'm struglling a bit to figure out how to do that given that I'm > trying to resort to using ToString(). > > > > If you call DataContext.SubmitChanges() after each operation (and disable > > ObjectTracking), you'll have the database always in sync with the in > memory > > one. > > Line 384 in DataContext.cs contains the snippet below which means it's > not possible to disable object tracking and call SubmitChanges(). Of > course I could comment out the check but I suspect it's there for a > purpose. > > public virtual void SubmitChanges(ConflictMode failureMode) > { > if (this.objectTrackingEnabled == false) > throw new InvalidOperationException("Object tracking > is not enabled for the current data context instance."); > .... > > Regards, > > Aaron > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
