dbmemo/dbgrid problem

[kjteng]

I noticed that changes in dbmemo are not saved when I moved to another record (in dbgrid). This happens if I am using Tzquery/TzMemtable (but not when I am using TMemDataset or Tdbf component).
Attached is the demo file.

[miab3]

Hi,

As if change detection for the memo field itself is missing.

Michał

[kjteng]

Ya, if I have add a line 'fields[x].asString := fields[x].asString (x is another field) then the memofield will be updated.
Is there a bug somewhere?

[marsupilami]

Is there a bug somewhere?

Hmmm - could you please check what happens if you disable the ZFields? I am not sure wether that has to happen in the Zeos.inc or in the properties of the dataset though...

Best regards,

Jan

[kjteng]

Hmmm - could you please check what happens if you disable the ZFields? I am not sure wether that has to happen in the Zeos.inc or in the properties of the dataset though...

You mean set the DisableZFields ? I tried ...same outcome whether disableZFields is True or False. The change in memofield would not be posted unless another field is edited.

[aehimself]

Issue seems to be Lazarus-specific, I can not reproduce the issue with latest Zeos from Git using D10.4 and D7.
Upon starting to type, ZMemTable properly fires both .BeforeEdit & .AfterEdit events, upon changing records in the DBGrid both .BeforePost and .AfterPost is fired. Modified data is correctly retained in ZMemTable.

As I have no Lazarus experience and therefore none installed I can not debug this. If you feel adventurous, this is what I'd do:

• Put a button on the form with the following code:

  Code: Select all

   ZMemTable1.Edit;
   Try
    If ZMemTable1.FieldByName('MemoField').IsNull Then ZMemTable1.FieldByName('MemoField').AsString := 'Test'
      Else ZMemTable1.FieldByName('MemoField').Clear;
   Finally
    ZMemTable1.Post;
   End;

• Create a dummy .BeforeEdit and .BeforePost event handler and put breakpoints in them
• Check which one is fired when editing manually
• Click on the button. When the execution stops in the event handler which did NOT fire manually, go back in the stacktrace and put some breakpoints in. Use step over to find the condition which eventually bocks the call
• Rinse and repeat until culprit is found