Once a TFDMemTable is set to Active at design time the TFieldDefs seem locked. It lets me change them when it is Active but it always reverts the changes after I reload the form. Is this a bug or is it some kind of Cache setting on TFDMemTable that is causing this? This StackOverFlow post talks about the issue a bit at Runtime: https://stackoverflow.com/questions/44874674/adding-a-new-field-to-fdmemtable-when-loading-an-existing-data
Once a TFDMemTable is set to Active at design time the TFieldDefs seem locked. It lets me change them when it is Active but it always reverts the changes after I reload the form. Is this a bug or is it some kind of Cache setting on TFDMemTable that is causing this? This StackOverFlow post talks about the issue a bit at Runtime: https://stackoverflow.com/questions/44874674/adding-a-new-field-to-fdmemtable-when-loading-an-existing-data
Uwe Raabe Tried that. It still lost the new field I added upon reloading the project.
ReplyDeleteI'm not sure I understand. FieldDefs determines runtime Fields when a dataset is set to active. At that point FieldDefs are ignored and Fields determine the dataset structure. When the table is closed, they might get reset, not sure... But I think this is part of TDataSet design. In theory, at design time FieldDefs should not be editable when the table is open.... but there might be a way to allow the behavior you ask. It is a very tricky area, with a lot of code and a lot of descendant components, so not sure this is something we'd change without a strong case
ReplyDeleteMy work around is I just use Save As File, go edit the database schema and data in the CDS_Main demo, and then Load As File again. An example would be I'm using a TListView for a menu. I add a NAME field to the schema and then fill in 5-10 rows with data (using the right click edit dataset). Then I figure out now I need another field. Can't add it without backtracking. Either going Active := False and losing the in memory data or using the workaround.
ReplyDelete