Validation in CRF not working if scape character '\' is used in the regular expression

Hello,

I have been working for years with OpenClinica 3.1 (PostgreSQL 8.4, tomcat 6.0.32).
Now we have just installed a new openclinica server, OpenClinica 3.11 (PostgreSQL 9.3, tomcat 7.0.52)
In this new server, many validation expressions of the items are not working. Same validations (CRF) are working in the oc 3.11 server.

After analysing we have found out that the validation does not work when it includes a regular expression using the scape character '\'.

For example, this validation:
regexp:/[1-3]\d{3}-\d{2}/

does not accept a value of 2001-01, openclinica shows the validation error message.

Can anyone help to fix this problem.

Many thanks,

Susana

Comments

  • lwhitelwhite Posts: 4
    I'm having the exact same issue. I've not found a solution yet, but I've only just come across the issue, if I find one i'll update.

    One thing to note is that we are only seeing the issue in the 3.11 Community edition. We are having no issues at all with regular expressions in 3.11 Enterprise edition, or 3.8 Community edition for that matter.

    I cannot see anything in OpenClinica's JIRA after a quick search, so i'll look at reporting the issue to them.
  • lwhitelwhite Posts: 4
    Just wanted to leave a quick update and post the solution we found to this issue.

    Previously we had been using the following regular expression for time (i.e. 24h clock, format hh.mm):
    regexp:/([0-1][0-9]|2[0-3])\.([0-5][0-9])|(-1)|/
    This is the one that no longer worked in 3.11 Community but worked in all previous versions.

    We are now using the following:
    regexp:/([0-1][0-9]|2[0-3])([.])([0-5][0-9])|(-1)|/
    And this works without issue in 3.8 and 3.11 Community edition. We've yet to test it in Enterprise though, but we don't expect to see an issue. If we do i'll comment on this once again.

    Hope that helps and you can adapt your expressions accordingly.
  • haenselhaensel Posts: 537 ✭✭
    lwhite said:


    We are now using the following:
    regexp:/([0-1][0-9]|2[0-3])([.])([0-5][0-9])|(-1)|/

    using the following regexp should work as well

    regexp:/([0-1][0-9]|2[0-3]).([0-5][0-9])|(-1)|/

    As far as I know OC isn't executing regular expressions on empty cells. The following expression should work as well

    regexp:/([0-1][0-9]|2[0-3]).([0-5][0-9])|(-1)/
  • FZweerusFZweerus Posts: 12
    We had a similar issue where the expression ‘regexp: /[0-1]\d:[0-5]\d|2[0-3]:[0-5]\d/’ did not work whereas ‘regexp: /[0-1][0-9]:[0-5] [0-9]|2[0-3]:[0-5][0-9]/’ did work fine.
    After some searching we found that the string that contained the expression was actually written incorrectly in the database. This was caused by the Postgress setting: ‘standard_conforming_strings ’

    From the Postgres documentation:
    “standard_conforming_strings (boolean)
    This controls whether ordinary string literals ('...') treat backslashes literally, as specified in the SQL standard. Beginning in PostgreSQL 9.1, the default is on (prior releases defaulted to off). Applications can check this parameter to determine how string literals will be processed. The presence of this parameter can also be taken as an indication that the escape string syntax (E'...') is supported. Escape string syntax (Section 4.1.2.2) should be used if an application desires backslashes to be treated as escape characters.

    After we changed this setting it was all working fine again.(We did have to store the expression in the database correctly again.) Please be aware that if this is the cause, you will possibly have multiple expressions stored incorrectly in the database by now.
Sign In or Register to comment.