| Subject | Re: Default value for Required property in TIBOQuery |
|---|---|
| Author | |
| Post date | 2018-10-24T16:50:48Z |
I'm having problems too. I wrote this once and now more than an hour later my two replies are still not showing so I'm going to try again.
I started typing out a long reply and in the middle I started to understand what the deal is. In design time when I created the query/fields it didn't have a database connection so it didn't know to auto assign True to Required. I don't think the BDE components tried to be that smart about it ever. We are running in to problems because in a few areas we are trying to post changes to an in-memory dataset where we don't necessarily care about the validity of every field all the time. A user might add or modify a number of records for instance in a grid and we might only sync it back in to the database when they hit save. In that scenario we may not care that the record is valid the whole time, but rather we might only validate when they hit save. If your dataset is directly tied to a database table where a post of the row pushes the changes directly in to the table then this required field is probably almost always desirable. But we are copying from a query dataset to a in-memory dataset where were validity is not necessarily required for every post. We ran in to another instance of this problem where we copied a dataset with say 10 fields to an in-memory dataset, but the code around that copy of the dataset only cared about 5 of those fields so additions to it would leave the unused fields blank. When we later sync the changes back to the database it is fine because we are only syncing back the 5 fields we cared about and ensured validity on while the other unused fields were not valid but also not synced to the db. Kind of silly that the code is copying fields / data it doesnt need when you think about, but w/e it was code that was working before converting to IBO but the strictness is biting us now because IBO is trying to be smarter about things.
Long story short, this is not a bug but rather just a change in behavior for us vs what the old Delphi 5 BDE components were doing. We are in the middle of converting a pretty large codebase from BDE to IBO and this is just something that was working before IBO but now breaks but regardless the default IBO behavior is probably the safest default.
I started typing out a long reply and in the middle I started to understand what the deal is. In design time when I created the query/fields it didn't have a database connection so it didn't know to auto assign True to Required. I don't think the BDE components tried to be that smart about it ever. We are running in to problems because in a few areas we are trying to post changes to an in-memory dataset where we don't necessarily care about the validity of every field all the time. A user might add or modify a number of records for instance in a grid and we might only sync it back in to the database when they hit save. In that scenario we may not care that the record is valid the whole time, but rather we might only validate when they hit save. If your dataset is directly tied to a database table where a post of the row pushes the changes directly in to the table then this required field is probably almost always desirable. But we are copying from a query dataset to a in-memory dataset where were validity is not necessarily required for every post. We ran in to another instance of this problem where we copied a dataset with say 10 fields to an in-memory dataset, but the code around that copy of the dataset only cared about 5 of those fields so additions to it would leave the unused fields blank. When we later sync the changes back to the database it is fine because we are only syncing back the 5 fields we cared about and ensured validity on while the other unused fields were not valid but also not synced to the db. Kind of silly that the code is copying fields / data it doesnt need when you think about, but w/e it was code that was working before converting to IBO but the strictness is biting us now because IBO is trying to be smarter about things.
Long story short, this is not a bug but rather just a change in behavior for us vs what the old Delphi 5 BDE components were doing. We are in the middle of converting a pretty large codebase from BDE to IBO and this is just something that was working before IBO but now breaks but regardless the default IBO behavior is probably the safest default.