Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 17 total |
changes to records are not always saved |
Sun, Mar 5 2006 5:33 PM | Permanent Link |
Bernd Kuhlmann | Hi,
our customers have reported that changes to a record are not always saved but that they seem to be canceled. I have posted a sample project to the binaries group. To reproduce the problem the following steps are needed: - start three instances of then program dbisamtest2.exe. - press "Empty" to delete all records from the table vorgang - press "Filltable" to create the test data - in each instance select 1, 2 or 3 in the programm radiogroup - press "Start test" in each instance sooner or later the memo shows the lines error wrong field value error record not saved This does not always happen, sometimes several runs are necessary. The program is essentially calling the following procedure in a while loop: procedure TForm1.DoVorgangLfs(id: Integer); var tb: Tdbisamtable; s: String; begin tb:=TdbisamTable.Create(nil); tb.tablename:='vorgang'; tb.open; if tb.FindKey([id]) then begin tb.edit; tb.FieldByName('Status').asString:='L'; tb.FieldByName('Status_Liefer_Nr').asInteger:=200; s:=tb.FieldByName('TXT_Oben').asstring; if tb.FieldByName('Status').asString<>'L' then begin // this should never happen memo1.lines.add('error wrong field value:'+tb.FieldByName('Status').asString+' vid: '+inttostr(id)); end; tb.post; if tb.FieldByName('Status').asString<>'L' then begin // this should never happen memo1.lines.add('error record not saved:'+tb.FieldByName('Status').asString+' vid: '+inttostr(id)); end; end else begin memo1.lines.add('vorgang not found:'+inttostr(id)); end; tb.close; tb.free; end; The problem is that changes to the field status (and other fields) are not always saved but the changes seem to be canceled. TXT_Oben is a memofield and the problem does not occur without accessing this field. The problem is rather urgent and any help would be appreciated. Bernd Kuhlmann |
Sun, Mar 5 2006 5:36 PM | Permanent Link |
Bernd Kuhlmann | Hi,
i forgot to mention that i am using dbisam V4.22 build 6. The problem occurs in both the file and the client server version. Bernd Kuhlmann |
Mon, Mar 6 2006 3:01 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Bernd
What happens if you add a Flushbuffers after the post? Roy Lambert |
Mon, Mar 6 2006 4:35 AM | Permanent Link |
Bernd Kuhlmann | Roy,
>What happens if you add a Flushbuffers after the post? The error occurs more frequently, so with flushbuffers it is easier to reproduce. The problem seems to be that the value of the field 'status' is wrong before the post. Bernd Kuhlmann |
Mon, Mar 6 2006 7:43 AM | Permanent Link |
Jon Lloyd Duerdoth | I had a problem where the content of a visual component was
not transferred to the underlying field until I left the field. Clicking a "Save" button on the form didn't save the value the user could see. Using a setfocus to some other field in the save routine was my workaround. Jon Bernd Kuhlmann wrote: > Roy, > >> What happens if you add a Flushbuffers after the post? > > The error occurs more frequently, so with flushbuffers it is easier to reproduce. > The problem seems to be that the value of the field 'status' is wrong before the post. > > Bernd Kuhlmann > |
Mon, Mar 6 2006 8:52 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Jon
Very good point - I'd forgotten that one. It doesn't catch me out in apps as much as altering properties in the IDE where the effect is the same. I've spent much happy time thinking why doesn't it work, I can see the new value and its not until I exit the field that the compiler realises its changed. Roy Lambert |
Mon, Mar 6 2006 9:00 AM | Permanent Link |
Bernd Kuhlmann | Jon,
>I had a problem where the content of a visual component was >not transferred to the underlying field until I left the >field. Clicking a "Save" button on the form didn't save >the value the user could see. Using a setfocus to >some other field in the save routine was my workaround. There are not visual components in the demo project, only a simple TDBISAMTable. So this is unfortunatly the solution. Bernd Kuhlmann |
Mon, Mar 6 2006 9:02 AM | Permanent Link |
Bernd Kuhlmann | Bernd Kuhlmann <bernd.kuhlmann@rita-bosse.de> wrote:
Jon, >I had a problem where the content of a visual component was >not transferred to the underlying field until I left the >field. Clicking a "Save" button on the form didn't save >the value the user could see. Using a setfocus to >some other field in the save routine was my workaround. >There are not visual components in the demo project, only a simple TDBISAMTable. >So this is unfortunatly the solution. this should of course be: So this is unfortunatly not the solution. Bernd Kuhlmann |
Mon, Mar 6 2006 10:24 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Bernd
I downloaded your app and had a play and came up with two solutions: 1. Wrap a transaction around the activity 2. Set Session.StrictChangeDetection to true I only ran one test with each but both seem to cure the problem. Its over to Tim for any more. Roy Lambert |
Mon, Mar 6 2006 12:06 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Bernd,
<< our customers have reported that changes to a record are not always saved but that they seem to be canceled. I have posted a sample project to the binaries group. >> It's a bug. Basically the BLOB change detection is refreshing the record during modification. A fix will be available shortly. -- Tim Young Elevate Software www.elevatesoft.com |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Friday, September 20, 2024 at 05:39 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |