Is this an issue with DBLINQ or is it LINQ? So I cannot use my loaded table objects that I have gotten from the datacontext and keep them and make changes..and then submit them? An example would be to connect them to a datagridview which works really well, with change to data etc,,as long as datacontext is alive. How do you propose that implement a system where I need the data avaialable for a long time and will make changes which needs to be commited now and then? I thought I could use these table objects as my "structs" and then simply commit them. I guess I need to keep them but copy their data to a newly loaded table object when I need to store to db?
/Peter, Sweden On 2 Okt, 16:14, Jonathan Pryor <[email protected]> wrote: > On Thu, 2009-10-01 at 23:10 -0700, Peete wrote: > > The issue I have is that once I have loaded data into my generated > > table objects and try to load them again, I get old data. > > I make changes to the database from another program after I have first > > loaded the dblinq objects. > > Note that I have one Datacontext object in my app which is alive the > > whole time. > > Don't do that. Seriously. Just Don't Do That. [0] > > > If I use locally created datacontext object then it loads > > the data correctly. > > Yeah. :-) > > > Is there some kind of caching of data? > > Yes. Caching is required in order to implement certain DataContext > behaviors [1]. > > > I have set QueryCacheEnabled to false but no difference. > > That does something completely different. It doesn't control caching of > entities, it controls caching of DbLinq-generated queries, so that a new > query doesn't need to be created anew. > > It's also horribly buggy (which is why it defaults to 'false', or > should). > > - Jon > > [0] Why not have a long-lived DataContext? For a number of reasons: > > 1. DataContext needs to cache all entity types returned from queries (so > that DataContext.SubmitChanges() can work [1]), so the longer the > DataContext lives, the larger the cache will become, and the more RAM > you'll use. This is...undesirable. > > 2. Large caches + lots of RAM use == slower performance (swapping = BAD) > > 3. DataContext wraps an IDbConnection, and IDbConnections CAN fail (due > to network errors, etc.; check the dblinq archives). Once the > IDbConnection is rendered invalid, the entire DataContext is also > invalid (because there's no way to "recreate" an IDbConnection instance > {unless the connection string provides the DbLinqConnectionType > parameter, but this doesn't help for the DataContext(IDbConnection) > constructor}). This is also bad. > > For best overall performance, and for best DB interaction behaviors, you > want the DataContext to live for as short a period as possible. > > [1] Example of required caching > > var db = CreateDB(); > var e = db.Employees.First(); > e.FirstName = "Something Different"; > db.SubmitChanges(); > > In order for the db.SubmitChanges() call to work, the DataContext needs > to know that 'e' exists, and thus store a reference to 'e' (so that it > can perform change tracking). This "stored reference" is a cache. QED. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
