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

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

Bernd


What happens if you add a Flushbuffers after the post?

Roy Lambert

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

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
>

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

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

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

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

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