From: bixbarton on
Hi, I've got a small program, using a DataSet and OracleDataAdapter.

Fills a table ok.

Loop through the rows ok.

Change a couple of values.

Then perform an Update on the OracleDataAdapter and it gives me the
dreaded...

"Concurrency violation: the UpdateCommand affected 0 of the expected 1
records."


I've searched all over the net for help on this, but nothing I find
seems to address the problem.

I've got no AcceptChanges in there.
I've tried FillSchema() before the Update()
I've tried setting any string.empty values to DBNull.

No joy.

And of course, there is no inner exception to provide more help.

Any help would be much appreciated, this is driving me crazy.

From: Mel Weaver on
I don't know much about Oracle but with SQL server each table must have a
primary unique key, if not you will get the concurrency error.



"bixbarton" <bixbarton(a)gmail.com> wrote in message
news:a9bc5498-e3f8-4a04-80ca-9a55e5459122(a)g19g2000yqc.googlegroups.com...
> Hi, I've got a small program, using a DataSet and OracleDataAdapter.
>
> Fills a table ok.
>
> Loop through the rows ok.
>
> Change a couple of values.
>
> Then perform an Update on the OracleDataAdapter and it gives me the
> dreaded...
>
> "Concurrency violation: the UpdateCommand affected 0 of the expected 1
> records."
>
>
> I've searched all over the net for help on this, but nothing I find
> seems to address the problem.
>
> I've got no AcceptChanges in there.
> I've tried FillSchema() before the Update()
> I've tried setting any string.empty values to DBNull.
>
> No joy.
>
> And of course, there is no inner exception to provide more help.
>
> Any help would be much appreciated, this is driving me crazy.
>
From: bixbarton on
Hi, yes it is very rare on Oracle.

I've checked, just in case, and the table I'm working with does have a
primary key.

Another oddity, is that I've discovered this problem is only happening
when you use the fresh QA version of our database. If you use the Dev
version used when it was built there are no issues. So trying to
ascertain whether there are differences inside the two databases, at
present it doesn't appear so.

Is there any way of debugging inside the Update operation, so that you
can see the individual SQL statements being run, rather than trying to
piece it together from the command templates on UpdateCommand with the
parameters?

I'm also trying to get a trace operation running on the Oracle DB like
a SQL Server Profiler to see if I can get the raw SQL statements.


On 13 June, 02:29, Arne Vajhøj <a...(a)vajhoej.dk> wrote:
> On 11-06-2010 11:37, Mel Weaver wrote:> "bixbarton" <bixbar...(a)gmail.com> wrote in message
> >news:a9bc5498-e3f8-4a04-80ca-9a55e5459122(a)g19g2000yqc.googlegroups.com....
> >> Hi, I've got a small program, using a DataSet and OracleDataAdapter.
>
> >> Fills a table ok.
>
> >> Loop through the rows ok.
>
> >> Change a couple of values.
>
> >> Then perform an Update on the OracleDataAdapter and it gives me the
> >> dreaded...
>
> >> "Concurrency violation: the UpdateCommand affected 0 of the expected 1
> >> records."
>
>  > I don't know much about Oracle but with SQL server each table must have
>  > a primary unique key, if not you will get the concurrency error.
>
> Note that this must be a DataAdapter/DataSet requirement, both
> Oracle and SQLServer actually allows tables with no PK.
>
> My guess is that it is extremely rare in Oracle database - if you
> can afford the Oracle license, then you can also afford to hire
> a DBA that has a clue.
>
> Arne

From: J.B. Moreno on
In article
<5d4ac229-9b3e-4903-92cb-56a0de448fd4(a)i31g2000yqm.googlegroups.com>,
bixbarton <bixbarton(a)gmail.com> wrote:

> Hi, yes it is very rare on Oracle.
>
> I've checked, just in case, and the table I'm working with does have a
> primary key.
>
> Another oddity, is that I've discovered this problem is only happening
> when you use the fresh QA version of our database. If you use the Dev
> version used when it was built there are no issues. So trying to
> ascertain whether there are differences inside the two databases, at
> present it doesn't appear so.
>
> Is there any way of debugging inside the Update operation, so that you
> can see the individual SQL statements being run, rather than trying to
> piece it together from the command templates on UpdateCommand with the
> parameters?

Do you mean something like:

string updStr = da.UpdateCommand.CommandText;

It's going to show the parameters, not their values, but you should be
able to figure out the values that went into by examining the exception
(take a look at Row).

--
J.B. Moreno
From: bixbarton on
Yeah, I've figured that out, I was hoping to avoid patching it
together myself, incase I miss any obvious bloopers caused by the
state of some of the parameters. If there's no avoiding it, then I
suppose I'll give it a go.

>
> Do you mean something like:
>
>    string updStr  = da.UpdateCommand.CommandText;
>
> It's going to show the parameters, not their values, but you should be
> able to figure out the values that went into by examining the exception
> (take a look at Row).
>
> --
> J.B. Moreno