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
-~----------~----~----~----~------~----~------~--~---
