In 2026.3.0 the date in the find/search gives us a warning

This problem now appears in version 2026.3.0. When performing a search using a date field, we receive the following warning:

*** The String type being assigned does not match the declared Date type of hr_fecha_calculo

Example usage:

foundset.find()
foundset.hr_date = utils.dateFormat(vl_date_1,‘yyyy-MM-dd’) + ’ 00:00:00…’ + utils.dateFormat(vl_date_2,‘yyyy-MM-dd’) + ’ 23:59:59|yyyy-MM-dd HH:mm:ss’
foundset.search()

The problem is that we are assigning a string to a date field, but this warning did not occur before.

Now we are getting many warnings.
Any suggestions on how to fix this problem?

Or should I create a support case for it?

Thanks, Roberto

no need for a case, this specific warning i think will always be there and can’t really be fixed.
Because suddenly the thing you assign can be a string because the record is in find mode, but the builder/validator doesn’t know that and can’t know that.

This will be fixable in the next release by suppressing that warning for that line (or on the function for everything in that function)

It would be important to remove the find/search warning in the next version.

One of our mottos is “0 warnings, 0 errors,” and this has flooded us with warnings, making it difficult to distinguish a genuine warning from this type of alert.
Thanks for your reply.
Regards, Roberto

Another way to prevent these would be to replace find/search with QueryBuilder statements. Find/search is always a bit “special” in a number of ways and can easily lead to errors, your code snippet being an example if the foundset cannot go into find mode (because it has open edits for example). Of course I am aware that it is no fun to go over hundreds of methods and replace usages of find/search, but in new code it might be wiser to switch to a loadRecords(qbSelect) approach.

Hi Patrick, we’re doing our latest projects as you suggested, with QueryBuilder.

The problem is that we also have multiple projects with find/search, and it would be very costly to replace code.

We’ll wait, as Jcompaner suggests, until the warning can be removed in future versions.