| Subject | Re: Default value for Required property in TIBOQuery |
|---|---|
| Author | |
| Post date | 2018-10-24T14:15:20Z |
Thanks for the response. I am thinking you might not have quite understood the failure scenario, because you are talking about clicking on your query at design time. Queries put on a form in design time work fine. The problem only arises when you are in a function, for instance, and create a query on the fly at runtime. Create the query in a function, give it some SQL and then check the fields it generates. You could have a query modeled exactly like the one you did at design-time, but the run-time version where the fields were autogenerated for you will have all the fields set to Required = True.
I was on 5.5 and yesterday I updated to 5.9 and this issue is still there. We are running Delphi 5. I have not made use of SchemaCache. I'm not very well versed in IBObjects yet. For a few years we have been using the native components in a few places, but this month we are undertaking a project where we are converting approximately 4000 BDE TQuery/TTable/TStoredProc to their IBO equivalents. A week or so ago when everything in the system was using BDE components this worked as expected and after converting to IBO now I have problems. I don't see anything in FieldOptions that is applicable. ColumnAttributes could fix it, but so can just setting the Required property to false. The problem is I really don't want to have to do this on all our queries and doing it at the TIBODatabase level means I have to assess 562 tables and determine which fields should be null. At the scale I am dealing with and because this all worked before IBO, I would really rather not have to go through all that work and possibly get it wrong anyway.
We wrote functionality in to the function we use to copy the TIBOQuery to the in-memory dataset that gives you the option to make all fields not required. Its a simple solution, takes very little effort per query, but it still means I have thousands of potential failure points out there until I stumble upon them and fix them. I would much prefer a fix that either makes on the fly run-time queries act the same as queries created at design-time or at least have a global setting that let's me opt in to this behavior if we are worried that fix might break other developers who expect this functionality. This is how the BDE components worked and it is how TIBOQuery works as long as you define the query and its fields at design-time. Defining a TIBOQuery at run-time is the odd man out so it really feels like a bug.
We wrote functionality in to the function we use to copy the TIBOQuery to the in-memory dataset that gives you the option to make all fields not required. Its a simple solution, takes very little effort per query, but it still means I have thousands of potential failure points out there until I stumble upon them and fix them. I would much prefer a fix that either makes on the fly run-time queries act the same as queries created at design-time or at least have a global setting that let's me opt in to this behavior if we are worried that fix might break other developers who expect this functionality. This is how the BDE components worked and it is how TIBOQuery works as long as you define the query and its fields at design-time. Defining a TIBOQuery at run-time is the odd man out so it really feels like a bug.