Please join your peers on either March 26 (8pm GMT) or March 28 (8am GMT) to watch as user extraordinaire and forum legend @"lindsay.stevens" demonstrates OpenClinica Insight.

See preview and register at

Insight makes it easy to ask questions of ALL of your clinical and operational data and visualize answers via interactive reports and dashboards. The idea is simple, but the results are powerful: ask your questions, choose your visualizations, then return often for updated, interactive results that link you to all of the underlying data.

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


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:

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

Can anyone help to fix this problem.

Many thanks,



  • 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
    This is the one that no longer worked in 3.11 Community but worked in all previous versions.

    We are now using the following:
    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: 570 ✭✭
    lwhite said:

    We are now using the following:

    using the following regexp should work as well


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

  • 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 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.