Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 8 of 8 total |
#8708 is not firing in the last 4.25b4 |
Thu, May 17 2007 3:59 PM | Permanent Link |
"Jose Eduardo Helminsky" | Tim
Recently I´ve upgrade from 4.22 b4 to 4.25b4 and I realize the error #8708 is not firing. 1) Start my app 2) Put some record in Edit mode 3) Start DBSys and change some field in the same record 4) Call POST in my application DOES NOT FIRE #8708 I´ve made the same test using my "old" 4.22b4 in the same way and it fires as expected. Tim |
Thu, May 17 2007 4:01 PM | Permanent Link |
"Jose Eduardo Helminsky" | Ops
It should by signed by Eduardo instead of Tim |
Fri, May 18 2007 3:19 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Eduardo,
<< Recently I´ve upgrade from 4.22 b4 to 4.25b4 and I realize the error #8708 is not firing. 1) Start my app 2) Put some record in Edit mode 3) Start DBSys and change some field in the same record 4) Call POST in my application DOES NOT FIRE #8708 >> Are you using optimistic or pessimistic locking ? -- Tim Young Elevate Software www.elevatesoft.com |
Fri, May 18 2007 3:55 PM | Permanent Link |
"Jose Eduardo Helminsky" | Tim
I am using optimistic locking. Eduardo |
Fri, May 18 2007 4:10 PM | Permanent Link |
"Jose Eduardo Helminsky" | Tim
After some tests, I realize it only happens when POST occurs inside a transaction (in my case *ALL* the times). I´ve comment out the StartTransaction and the #8708 fires as expected. Eduardo |
Tue, May 22 2007 8:19 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Eduardo,
<< After some tests, I realize it only happens when POST occurs inside a transaction (in my case *ALL* the times). I´ve comment out the StartTransaction and the #8708 fires as expected. >> In that case the behavior is correct. The StartTransaction does a "check for changes" when it executes, therefore it is impossible for there to be any changes found during any post. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, May 23 2007 6:15 AM | Permanent Link |
"Jose Eduardo Helminsky" | Tim
Let me try again. Something were changed in the engine. Using C/S with oportunistic locking Computer 1: Put a record in Edit mode and wait to user input. Computer 2: Put a record in Edit mode, make some changes and Post the record Computer 1: Start to post the record previously in edit mode. Start a transaction Post the record. <---- In this step, it would have to fire #8708 because record was really changed by other user, but it ignores any other changes and save the record changed by Computer 1. I always use transaction in this manner: Database.StartTransaction; Table.Post; Database.Commit; It only happens in 4.25 b4. The same situation in 4.22 b4 works like expected. > In that case the behavior is correct. The StartTransaction does a "check > for changes" when it executes, therefore it is impossible for there to be > any changes found during any post. Like the above example, this "check for changes" is not working. I am using restricted transaction but I´ve checked and it is not working with a global transaction. Eduardo |
Thu, May 24 2007 5:06 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Eduardo,
<< Let me try again. Something were changed in the engine. Using C/S with oportunistic locking Computer 1: Put a record in Edit mode and wait to user input. Computer 2: Put a record in Edit mode, make some changes and Post the record Computer 1: Start to post the record previously in edit mode. Start a transaction Post the record. <---- In this step, it would have to fire #8708 because record was really changed by other user, but it ignores any other changes and save the record changed by Computer 1. >> Okay, I've got the problem now. It will be fixed in the next 4.25 build. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Saturday, April 27, 2024 at 08:52 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |