What is Web Core equivalent of VCL "DisableControls" for DB components?

[Peterson_Terry (Terry Peterson)]

I have the following working method for color-coding a data table. However, it seems to cause a lot of overhead such that tables with more than a hundred, or so, cells take way too long to update. In a VCL app I think I could use DBG.DisableControls/EnableControls to mitigate this slowdown, but those methods appear not to be included for TWebDBGrid. What should I do instead?

procedure TCWRmainFrm.WebDBGrid1GetCellClass(Sender: TObject; ACol,
  ARow: Integer; AField: TField; AValue: string; var AClassName: string);
{ show listings in color code for type based on current IDB record }
var
  AColor: string;
  Text: string;
begin
  if ARow = 0 then exit;
  // Prevent recursion
  WebDBGrid1.OnGetCellClass := nil;
  AClassName := 'redfont';
  AColor := '';
  if WIDBCDS.Locate('id', WebDBGrid1.Cells[3,ARow],[]) then
  begin
    Text := WIDBCDS.Fields[8].AsString; // i.e. ProgramID
  //  if not Text.Contains('EP') then console.log(Text);
    if Text.Contains('MV') then  // Movie item
      AColor := 'goldenRod'
    else if Text.Contains('SH') then  // Generic item
      AColor := 'gray'
    else begin
      if WIDBCDS.Fields[10].AsString <> '' then  // New item
        AColor := 'green'
      else                                // Rerun item
        AColor := 'rose';
    end;
    if AColor > '' then AClassName := AColor;
  end;
  // Restore link
  WebDBGrid1.OnGetCellClass := WebDBGrid1GetCellClass;
end;

[brunofierens]

Is WIDBCDS the dataset also connected to this same grid?
The dataset itself has DisableControls / EnabledControls. Did you try to use that?

[Peterson_Terry (Terry Peterson)]

Thanks, Bruno. Yes, the DataSource does link WIDCDS and the DBGrid. I was fixated on the dbgrid, so I didn't think of looking "upstream". Disabling controls on WIDBCDS does seem to be the right approach although I haven't yet worked out where/when to do it to get the desired speedup!

Also, I must be doing something wrong in setting up the IDB, as it reports as "empty" sometimes when its RecordCount > 0. Any idea about how that occurs? This is a problem when I want to dump the old records but while not WIDBCDS.IsEmpty do WIDBCDS.Delete fails to "clear the board". Is there a better way to delete the IDB (as can be done in the Dev Tools UI) and start over?

[brunofierens]

I would really need more context and details. I have no idea what IDB is and what exact code you use here.

[Peterson_Terry (Terry Peterson)]

I created the IDB following the code in the Demos\Basics\IndexedDB project. I've only seen the erroneous WIDBCDS.IsEmpty result after having also seen an error message about "too much recursion" when my GetCellClass method was active. So I think that it's not likely to appear now that I've started using WIDBCDS.DisableControls to avoid slowdowns. (Thanks again for the tip) But if it does recur I'll try to provide more context.

[brunofierens]

OK, if possible isolate & provide some sample source project with which we can reproduce this

[Peterson_Terry (Terry Peterson)]

I don't have the isolated example yet, but I'm thinking that my puzzling results may have to do with interactions between disabling the WIDBCDS controls and using Filtered=True/False. The IsEmpty method seems to get confused if filtering is enabled. How should it work, should it track the number of filtered records or the total?

A related question: I have found that the WebIndexedDataBaseClientDataset.RecordCount does not follow the number of filtered records. Is that as designed?

I would expect that filtering, record counting, and IsEmpty would not be affected by disabling controls. Is that not right?

Can you point me to a reference on these subjects, please?

[brunofierens]

Information I have from pas2js team, responsible for RTL TDataSet, RecordCount is not taking filtering in account.

[Peterson_Terry (Terry Peterson)]

Thanks for the confirmation. (Maybe someday they'll get around to adding the FireDAC property RecordCountMode that controls that)

I'm still in head-scratching mode here. I've accomplished significant speedup using WIDBCDS.Disable|EnableControls and WebDBGrid.Begin|EndUpdate but I'm still encountering some IDB corruption at times.

[Peterson_Terry (Terry Peterson)]

OK, I think I've finally sorted out the root cause of the IDB corruption and subsequent strange results. It may be a Web Core bug! I'll try to form a simple test project for you to recreate the issue.

[Peterson_Terry (Terry Peterson)]

Not a specific test project yet, but your ToDoList demo now seems broken by a related change in the current beta. It produces this when run as-is from the demo store:

The cause is evidently a conflict between the IDBCDS properties and the FieldDefs.Add instruction for id in WebFormCreate, which has both an incorrect "true" and an apparent extra parameter "3". Changing "true" to "false" eliminates the runtime error and removing the "3" eliminates the LSP error about too many parameters (with unknown consequence):

procedure TForm1.WebFormCreate(Sender: TObject);
begin
  application.OnImageCacheReady := WebFormShow;

  // Setup permanent indexes
  IndexedDBClientDataSet.AddIDBIndex('ByDate', 'due_date');
  IndexedDBClientDataSet.AddIDBIndex('ByStatus', 'status');
  IndexedDBClientDataSet.AddIDBIndex('ByDescr', 'descr');
  IndexedDBClientDataSet.IDBActiveIndex := 'ByDate';

  WebDataSource1.DataSet :=  IndexedDBClientDataSet;

  IndexedDBClientDataSet.FieldDefs.Clear;

  // add key field
  IndexedDBClientDataSet.FieldDefs.Add('id',ftInteger, 0, **true**, **3**);
  // make it a hidden column
  IndexedDBClientDataSet.FieldDefs.Items[0].Attributes :=  IndexedDBClientDataSet.FieldDefs.Items[0].Attributes + [faHiddenCol];

  // add normal fields
  IndexedDBClientDataSet.FieldDefs.Add('status',ftString);
  IndexedDBClientDataSet.FieldDefs.Add('descr',ftString);
  IndexedDBClientDataSet.FieldDefs.Add('due_date',ftDate);

end;

Curiously, this incompatibility between the IDBCDS component property and the WebFormCreate FieldDefs.Add code, as well as the extra "3" parameter, also exist in Holger Flick's 2nd Edition TMS Web Core book (pp: 446-447)!

In my own project, I had followed an earlier version of the ToDoList demo, in which the FieldDefs.Add instruction had "true" (but no 5th parameter). I then saw the same runtime error message, so I added an instruction to insert the id field. That removed the runtime error message and FireFox DevEd didn't throw any other immediate errors or related warnings. However, the conflict between the IDBCDS component's "autoincrement=true" and my manual insertion of the id field value seems to have led to several later errors and eventual corruption of the IDB.

When I finally tested using the MS Edge browser, I saw a warning about this conflict in the dev console.

P.S.: The Pictures demo has the same incompatible-parameters issue.

[Peterson_Terry (Terry Peterson)]

I finally noticed the new 2.6 RC download and installed it this morning. I see that the demos and the documentation all still give incorrect guidance about setting up the id field for autoincrementing DB, saying that the Required value should be "true" when it actually must be "false". Also, I can find no documentation on that 5th parameter that's always "3" in the examples.

Here is where the Edge browser stopped when I clicked on the New Task button of the RC's ToDoList demo:

[brunofierens]

We fixed this demo and we fixed the doc. Release will have these fixes.