Clientdataset : ApplyUpdates with err 'Record not found' ( with upWhereKeyOnly )
Deberlanger Dirk
I'm on D7 trying to migrate an application from BDE to MySQL 3.23
/dbexpress.
For starters, I wanted to quickly write a table by table / record by record
migration that allows me to run in parallel for a while.
I'm struggling very hard with transferring changes from source to target
inserts seem no problem )
I have setup a classic Clientdataset ->Datasetprovider -> SQLDataset
When trying to post modifications back to the database, I'm getting 'Record
not found or changed by another user'. I'm using 'wherekeyonly' and verified
that only the key fields have the provider flag set for including the key.
I've even monitored the SQL statement and also that one seems ok ( when I
copy and paste into a MySql utility, it runs without any problem ) :
update ARTIK set
Art_aankoop_korting_type1 = '',
Art_aankoop_korting_type2 = '',
Art_aankoop_korting_type3 = ''
where
Art_id = '13280.0'
I've tried literally a zillion things and nothing seems to help....I
managed to find out that these records are being 'updated' -- even though no
real updats have occurred to the source record -- because the source table
has character fields with spaces, while the ClientDataset trims trailing
spaces and my comparison routine for field values reports this as a 'change'
and subsequently generates a update to the clientdataset.
I have found some similar problems reported but the answer was mostly that
the update mode was not correctly set. Other causes seem to be a date fields
( which I have in my table but not in the key and not used in this update
SQL statement )
I've also activated and explored the mysql log and also there, the correct
SQL statements seem to enter the database processes.
Am I overlooking something afterall or is it a bug ?
Any help very much appreciated
Regards
Dirk
Eduardo Andrade Bahiense
BDE to MYSQL.
I was having the same problem and I found that
if I did Edit->Post->ApplyUpdates twice on the same
record then I Got the error.
I worked around Applying Updates after the last post.
It worked for me even using upwhereall.
I also would like to have a better explanation.
cheers, Eduardo
"Deberlanger Dirk" <tri...@pandora.be> escreveu na mensagem
news:3f09f1ff$1...@newsgroups.borland.com...
Dave Rowntree
Crossposted.
Please do not cross-post or multi-post. It is against Borland
newsgroup rules, and wastes everbody's time.
You can read the rules here:
http://info.borland.com/newsgroups/guide.html#rules
Thank you.
--
Dave Rowntree
Dave Rowntree
being raised by MIDAS(datasnap). It is raised when the number of
records reported to have been updated (by the DB through the data
access layer) is zero.
The problems you are seeing may well be related to the problem
described in QC#4504. There are workaround fixes provided against
QC#4504.
--
Dave Rowntree
Kevin Frevert
That error can be a little misleading. Basically the driver looks for a
return message from the server notifying the client on how many records were
affected/changed. If the message returns anything but 1, you get an error.
What can cause the 'confusion'? Float-type primary keys (floats, money,
datetime, etc), triggers affecting other records, where clause affecting
more than 1 record, or the record actually changed from the last time it was
read (optimistic locking).
Good luck,
krf
"Deberlanger Dirk" <tri...@pandora.be> wrote in message
news:3f09f1ff$1...@newsgroups.borland.com...
> Hi,
>
> update ARTIK set
> Art_aankoop_korting_type1 = '',
> Art_aankoop_korting_type2 = '',
> Art_aankoop_korting_type3 = ''
> where
> Art_id = '13280.0'
Dave Rowntree
<snip>
>That error can be a little misleading. Basically the driver looks for a
>return message from the server notifying the client on how many records were
>affected/changed. If the message returns anything but 1, you get an error.
Not necessarily. Mulitple record updates are allowed in MIDAS if the
DSP.Option poAllowMultiRecordUpdates is set. Besides, the error raised
against a multi-record update (when the DSP.Option
poAllowMultiRecordUpdates is not set) is not 'Record not found or
changed by another user', it is 'Update affected more than 1 record.'
<snip>
>, triggers affecting other records, where clause affecting
>more than 1 record,
See above.
--
Dave Rowntree
Deberlanger Dirk
rules before adding my first post to the newsgroups.
I will keep it in mind as of now
THx
Dirk
"Dave Rowntree" <daver@spam_offbrookswood.co.uk> wrote in message
news:061lgvkop456ngqd1...@4ax.com...
Deberlanger Dirk
The reference versus QC#4504 is indeed what's causing my problem. Once I
prohibit any 'fake' changes to be posted against the DB, the problem
disappears as quickly as it came. Any real change posts without a problem.
I wasn't familiar at all with Quality Central ( only Code central ) so
that's why I have missed the obvious previous posts regarding this problem.
But now I'm up and running in QC and will add this at the top of my 'first
aid' toolbox.
sincerest thanks
Dirk
For those who have the time....
There are few moments when you experience the same thrills again as when
first discovering the amazing DELPHI development tool. This experience was
definitly one of them. After long consecutive evenings of trial and error,
starting over again from scratch, dream about pascal code, wake up with new
ideas, racing through the day job to try them out and...watch them fail
again by a mercyless exception message, but yet keep refusing to throw in
the towell. These and other familiar scenarios to all of you. Then you post
a message to a newsgroup and few hours later , a solution or workaround is
delivered at your fingertips. Miracles do happen.
"Dave Rowntree" <daver@spam_offbrookswood.co.uk> wrote in message
news:3o1lgvkt2179k9jit...@4ax.com...
Dave Rowntree
>Dear Mr Rowntree,
Dave is fine.
>The reference versus QC#4504 is indeed what's causing my problem. Once I
>prohibit any 'fake' changes to be posted against the DB, the problem
>disappears as quickly as it came. Any real change posts without a problem.
>I wasn't familiar at all with Quality Central ( only Code central ) so
>that's why I have missed the obvious previous posts regarding this problem.
>But now I'm up and running in QC and will add this at the top of my 'first
>aid' toolbox.
Glad it solved the problem. Another place worth visiting is Google:
http://www.google.com/advanced_group_search?hl=en
Archives of these newsgroups are available there.
--
Dave Rowntree