Thanks for info. But to copy every field was what I was trying to
avoid. Since there is no "Assignment" operator
for this generated class I thought I could use the code as I did.

Any idea if Attach is going to work in the future? I read about "LINQ
to SQL" had that function.
Is it in DBLINQ it is not working at the moment?

/Peter, Sweden

On 6 Okt, 23:10, Jonathan Pryor <[email protected]> wrote:
> Table<T>.Attach(TEntity, TEntity) is not working (based on the fact that
> the Table.Attach04() test is currently marked as [Explicit]).
>
> Furthermore, once you detach an entity it won't have changes tracked.
>
> So as a workaround I would suggest the "brute force" approach:
>
>         UserAccount user = thedb.UserAccount.FirstOrDefault(
>                 u => u.IDUserAccount == useraccount.IDUserAccount);
>         if (user != null) {
>                 user.Name    = useraccount.Name;
>                 user.Address = useraccount.Address;
>                 // ...
>         }
>         thedb.SubmitChanges();
>
> That is, once you find the matching record from the DB (based on primary
> key), manually update all of it's properties to match your detached
> record.  Since the record you just looked up will have change tracking
> enabled, assigning the properties will ensure that on the
> SubmitChanges() call the record will be updated.
>
> This isn't ideal, but it should work...
>
>  - Jon
>
>
>
> On Tue, 2009-10-06 at 11:12 -0700, Peete wrote:
> > I have now tried by using new datacontext object.
> > Works great on loads ofcourse.
> > I cant get update to work though. I use Attach method.
> > The way I use it below gives me DuplicateKeyException.
> > Note that my table has IDUserAccount(int) as Primary Key.
> > the useraccount variable is loaded in another function and is fetched
> > from a datacontext the same way as how the tmpaccount variable is set.
> > Any suggestions?
>
> > public override bool SaveDataToDB()
> >             {
> >                 ClassFactory fact = ClassFactory.Instance;
> >                 MyDB thedb = new MyDB
> > (fact.TheDataBaseConnection);
> >                 try
> >                 {
> >                     if (_loaded)
> >                     {
> >                         IQueryable<UserAccount> users = from h in
> > thedb.UserAccount
> >                                                         where
> > h.IDUserAccount == useraccount.IDUserAccount
> >                                                         select h;
>
> >                         long lcount = users.Count();
> >                         if (lcount == 0)
> >                         {
> >                             System.Windows.Forms.MessageBox.Show("No
> > data found!");
> >                             return false;
> >                         }
> >                         else if (lcount > 1)
> >                         {
> >                             System.Windows.Forms.MessageBox.Show("More
> > than one row found matching User ID:" +
> > useraccount.IDUserAccount.ToString());
> >                             return false;
> >                         }
>
> >                         UserAccount tmpaccount = users.First();
>
> >                         thedb.UserAccount.Attach(useraccount,
> > tmpaccount);
> >                     }
> >                     else
> >                     {
> >                         useraccount.AccountCreation = DateTime.Now;
> >                         useraccount.LastValidLogin = DateTime.Now;
> >                         Table<UserAccount> useraccounttable =
> > thedb.GetTable<UserAccount>();
> >                         useraccounttable.InsertOnSubmit(useraccount);
> >                     }
>
> >                     thedb.SubmitChanges();
> >                 }
> >                 catch (MySqlException ex)
> >                 {
> >                     System.Windows.Forms.MessageBox.Show(ex.Message);
> >                     return false;
> >                 }
>
> >                 return true;
> >             }
>
> > On 4 Okt, 13:57, Peete <[email protected]> wrote:
> > > 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.- Dölj citerad text -
>
> > > - Visa citerad text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to