The reason I don't use version checking is that it's a fairly big
database, so implementing those columns is a non-trivial task.
You are correct, I do have the the data detached.
I just don't get why if i have column a and b. I modify column a in my
program, and b outside of the program, then when i save the row in the
program it alters both a and b.
About the code for getting the datagridview populated, here goes:
I have built my code base just as in the brief tutorial in the
NHibernate docs. that is one "tabeldef.hbm.xml" file, one "table.cs"
file, one "tablerepository.cs" file.
the following is the code in my form, for loading the data into the
datagridview.
I have removed a few lines of code, that runs the form as a singleton,
and also code for pasting data into the datagridview, for
readability's sake. (also I did not use those features while
bughunting)
TblLeverandoerBindingSource, and dataGridView1 are defined in the
windows designer in visual studio.
---CODE BEGIN---
using System;
using System.Windows.Forms;
using UtilityFunctions;
using System.Data;
using System.Collections.Generic;
using PhkreaturNHibernate;
namespace KreaturSystem
{
public partial class LeverandoererForm : Form
{
PhkreaturNHibernate.TblLeverandoerRepository levRepos = new
PhkreaturNHibernate.TblLeverandoerRepository();
public LeverandoererForm()
{
InitializeComponent();
}
private void FormLeverandoerer_Load(object sender, EventArgs e)
{
this.WindowState = FormWindowState.Maximized;
dataGridView1.AutoGenerateColumns = true;
TblLeverandoerBindingSource.DataSource =
levRepos.GetAll();
dataGridView1.DataSource = TblLeverandoerBindingSource;
dataGridView1.Columns["PK_ID"].Visible = false;
}
private void dataGridView1_UserDeletingRow(object sender,
DataGridViewRowCancelEventArgs e)
{
levRepos.Remove(((TblLeverandoer)TblLeverandoerBindingSource.Current));
}
private void dataGridView1_RowValidating(object sender,
DataGridViewCellCancelEventArgs e)
{
if (dataGridView1.NewRowIndex !=
dataGridView1.Rows[e.RowIndex].Index)
{
levRepos.Update(((TblLeverandoer)TblLeverandoerBindingSource.Current));
}
}
}
}
---CODE END---
On Jun 3, 1:54 pm, TheCPUWizard <[email protected]> wrote:
> While that may be true for nHibernate, I question if the premise of "optimal
> strategy" can be substantiated as a general case, especially when
> non-conflicting updates [ie independent columns] are considered. My
> experience with many (non-nHibernate related) concurrent systems does not
> support such a premise.
>
>
>
>
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
>
> Of Oskar Berggren
> Sent: Sunday, June 03, 2012 7:06 PM
> To: [email protected]
> Subject: Re: [nhusers] Re: optimistic-lock="all" does not throw exception as
> expected
>
> A paragraph in section 5.1.3 of the reference also relates to this:
>
> "We very strongly recommend that you use version/timestamp columns for
> optimistic locking with NHibernate. This is the optimal strategy with
> respect to performance and is the only strategy that correctly handles
> modifications made outside of the session (ie. when ISession.Update() is
> used). Keep in mind that a version or timestamp property should never be
> null, no matter what unsaved-value strategy, or an instance will be detected
> as transient."
>
> /Oskar
>
> 2012/6/2 Michael Abraham <[email protected]>:
> > When you use dynamic-update="true" optimistic-lock="all", NH will
> > issue an update like
>
> > update <table> set <col1>=<newval1>, <col2>=<newval2>, ... where
> > <idcol>=<idval> and <col1>=<oldval1> and <col2>=<oldval2>.
>
> > <col1>, <col2>, ... are the columns that NH thinks you have modified
> > from their original values. If the instance is attached, that works.
> > But if the instance is detached, NH has no way to figure out the
> > original values of the columns. So you also need
> > select-before-update. That causes a select (to get the "original"
> > values) before the update, but that select happens after you have made
> > your change via SSMS. One option would be to reattach the instance
> > before updating it with the new values in the grid, e.g., doing
> > someting like session.Lock(instance, LockMode.None) (I may have the
> > syntax wrong). If you don't need to use dynamic-update, you might be
> better off using a timestamp column for concurrency control.
>
> > Mike
>
> > On Friday, June 1, 2012 8:05:49 AM UTC-4, imonsei wrote:
>
> >> I have defined a class, and set
>
> >> dynamic-update="true" optimistic-lock="all" select-before-
> >> update="true"
>
> >> in my tabledefiniton hbm.xml file.
> >> I start my program and load my data in displaying it in a
> >> datagridview.
> >> Next I load up sql management studio (mssql2008 express), connect to
> >> the database, and alter an entry in the table i have just loaded into
> >> the program.
> >> Meanwhile in the program I make sure the change has not propergated
> >> into the datagridview.
> >> Now I change something in the row I had altered with sql management
> >> studio.
> >> I save my change from the datagridview to the database.
>
> >> What I expected was an exception being thrown by the program, but
> >> instead I find that the change I made with sql management studio has
> >> been overwritten completely with the other data from my program.
>
> >> Can anyone take a stab at where I go wrong?
> >> PS. just say and I'll post the code I use, if you need it.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "nhusers" group.
> > To view this discussion on the web visit
> >https://groups.google.com/d/msg/nhusers/-/HOscx0WG0i8J.
>
> > 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/nhusers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" 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
> athttp://groups.google.com/group/nhusers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"nhusers" 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/nhusers?hl=en.
