[SOLVED] Query date 1 >= date 2 doesn't work

2. date may not before the 1. date, could you please assist here, should be easy but I have not configured it right, because it doesn't work

This I have filled in into the 2. date (1. date = cb_tauschdatum_ab")

And is it possible to get the system message from this field query also in profile inline editing?

You can try converting the string date to a timestamp then compare by changing '[value]' to UNIX_TIMESTAMP( '[value]' ). Beyond that it should be working as is as long as it's a date column compared against a date value.

It however isn't going to compare the currently changed value of cb_tauschdatum_ab against the value you're supplying as it's just comparing against the stored value. So as long as cb_tauschdatum_ab has already been saved it'll work as expected.

And is it possible to get the system message from this field query also in profile inline editing?

Don't understand what you mean by this.

Thanks, I tried further an this works: SELECT id FROM XXXX_comprofiler WHERE cb_tauschdatum_ab < "[value]"

To "And is it possible to get the system message from this field query also in profile inline editing? // Don't understand what you mean by this.":

I asked, whether it works also with the inline editing in the profile, not only in the edit modus of the profile.

Yes, the validation should work fine when using inline editing provided by CB Core Fields Ajax.

ericmuc wrote: Thanks, I tried further an this works: SELECT id FROM XXXX_comprofiler WHERE cb_tauschdatum_ab < "[value]"

Unfortunately is doesn't work right:

SELECT id FROM XXXX_comprofiler WHERE cb_tauschdatum_ab < "[value]"
SELECT id FROM acmp6_comprofiler WHERE cb_tauschdatum_ab < UNIX_TIMESTAMP ("[value]")
SELECT id FROM XXXX_comprofiler WHERE UNIX_TIMESTAMP (cb_tauschdatum_ab) < UNIX_TIMESTAMP ("[value]")

All this queries have following results:
from the date in the data bank shown as "2019-07-01" only the year is taking for the validation, so all inputs like 2019-08-01 or 2019-06-01 are wrong, but 2020-xx-xx is right.

What now? That is a basic function and I woud like to use further like this in my installation.