Concurrency violation: the UpdateCommand affected 0 of the expected 1 records.
in [CSharp]
|
From: bixbarton on 15 Jun 2010 06:51 On 14 June, 19:05, Harlan Messinger <hmessinger.removet...(a)comcast.net> wrote: > Arne Vajhøj 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. > > Possibly. I had a similar situation years ago, when beginning to work on > an existing application, and using Microsoft Access to work with SQL > Server data. I'd get an error message when I'd try to delete a row in > some tables--and then discovered that primary keys had been defined for > them. How annoying, I constructed the update command from the template in UpdateCommand and applied the parameter values (cheated by dropping in at UpdatingRow point and getting it to do all the parsing for me). Ran the command manually in SQLPlus, no problems. And yet the update as part of the DataSet still gives the concurrency error. Grr... no useful error messages.
From: bixbarton on 15 Jun 2010 10:08 On 15 June, 11:51, bixbarton <bixbar...(a)gmail.com> wrote: > On 14 June, 19:05, Harlan Messinger > > > > > > <hmessinger.removet...(a)comcast.net> wrote: > > Arne Vajhøj 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. > > > Possibly. I had a similar situation years ago, when beginning to work on > > an existing application, and using Microsoft Access to work with SQL > > Server data. I'd get an error message when I'd try to delete a row in > > some tables--and then discovered that primary keys had been defined for > > them. > > How annoying, I constructed the update command from the template in > UpdateCommand and applied the parameter values (cheated by dropping in > at UpdatingRow point and getting it to do all the parsing for me). > > Ran the command manually in SQLPlus, no problems. > > And yet the update as part of the DataSet still gives the concurrency > error. > > Grr... no useful error messages. I've even stripped the DataSet UpdateCommand back to only the bare few columns that need updating. UPDATE LE_PALC_REQUEST SET ACCEPTANCE_SENT_LAST_ATTEMPT = :LastAttempt, ACCEPTANCE_RECEPTION_CODE = :RecCode, ACCEPTANCE_RECEPTION_ERROR = :RecError WHERE (INTERNAL_ID = :Original_INTERNAL_ID) Then submitted the exact same LastAttempt, RecCode and RecError parameters in four updates. LastAttempt from DateTime.Now RecCode = 0 RecError = null The only difference between the attempts is the Original_INTERNAL_ID identifying which record we're updating. 126 works 127 fails 131 fails 165 works Utter madness...
From: bixbarton on 18 Jun 2010 04:51 On 15 June, 15:08, bixbarton <bixbar...(a)gmail.com> wrote: > On 15 June, 11:51, bixbarton <bixbar...(a)gmail.com> wrote: > > > > > > > On 14 June, 19:05, Harlan Messinger > > > <hmessinger.removet...(a)comcast.net> wrote: > > > Arne Vajhøj 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. > > > > Possibly. I had a similar situation years ago, when beginning to work on > > > an existing application, and using Microsoft Access to work with SQL > > > Server data. I'd get an error message when I'd try to delete a row in > > > some tables--and then discovered that primary keys had been defined for > > > them. > > > How annoying, I constructed the update command from the template in > > UpdateCommand and applied the parameter values (cheated by dropping in > > at UpdatingRow point and getting it to do all the parsing for me). > > > Ran the command manually in SQLPlus, no problems. > > > And yet the update as part of the DataSet still gives the concurrency > > error. > > > Grr... no useful error messages. > > I've even stripped the DataSet UpdateCommand back to only the bare few > columns that need updating. > > UPDATE LE_PALC_REQUEST SET ACCEPTANCE_SENT_LAST_ATTEMPT > = :LastAttempt, ACCEPTANCE_RECEPTION_CODE = :RecCode, > ACCEPTANCE_RECEPTION_ERROR = :RecError WHERE (INTERNAL_ID > = :Original_INTERNAL_ID) > > Then submitted the exact same LastAttempt, RecCode and RecError > parameters in four updates. > > LastAttempt from DateTime.Now > RecCode = 0 > RecError = null > > The only difference between the attempts is the Original_INTERNAL_ID > identifying which record we're updating. > > 126 works > 127 fails > 131 fails > 165 works > > Utter madness... I'm still getting nowhere with this. Think I'm going to have to dump the use of DataSets and just handcode the DB transactions. Shame that DataSets aren't more transparent.
First
|
Prev
|
Pages: 1 2 Prev: Loss of network Connection Next: Cannot convert 'ref byte[]' to 'ref byte' |