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