We hope you'll join us for our 4/23 webinar on using data tables to apply reference ranges and AE codes in OC4. For more information and to register, visit https://register.gotowebinar.com/register/2882170018956684555

Text area size

(i.e. the text datatype in postgres) ?
Thanks David

Comments

  • davehdaveh Posts: 7
    Hi all
    After further digging I can see that the limitation is hard coded in a lot of places and that openclinica is using the varchar(n) data format where n is typically 255.
    Is there any reason to limit data entry to 255 characters for any field ?
    the native storage in postgres is pretty much unlimited and even oracle can manage 4000 characters.
    http://www.postgresql.org/docs/9.0/interactive/datatype-character.html
    Thanks David
    > The text area size is limited (according to the docs) to 255 characters Is there any way to increase this to unlimited
    > (i.e. the text datatype in postgres) ?
    >
    > Thanks David
    >
    >
    >
  • zirbyclinicazirbyclinica Posts: 29
    Dear developers,
    I made one rule to compare two dates between two different visit (events) in my study.


    SE_VISIT3DAY141.F_PATIENTQUEST_506_V11.IG_PATIE_UNGROUPED_398.I_PATIE_SV3_QUEST_DT_2262


    This date must be greater then the date last visit




    Difference date
    SE_VISIT3DAY141.F_PATIENTQUEST_506_V11.IG_PATIE_UNGROUPED_398.I_PATIE_SV3_QUEST_DT_2262 gt SE_VISIT2DAY71.F_PATIENTQUEST_968_V11.IG_PATIE_UNGROUPED_398.I_PATIE_SV2_QUEST_DT_6253


    No invalid remarks, BUT it does not work!!
    Can anyone help me to compare two dates,
    Thanks in advance.
    Christian
  • GerbenRienkGerbenRienk Posts: 837 ✭✭✭
    Hi Christian,

    Just to make sure I get this right:
    You want to compare two dates, on two different Events (SE_VISIT3DAY141 and SE_VISIT2DAY71).
    The dates are on on two different CRFs or CRF versions (F_PATIENTQUEST_506_V11 and F_PATIENTQUEST_968_V11)
    But the ItemGroups are on both CRFs are the same (IG_PATIE_UNGROUPED_398)

    Can you confirm this is right and that the CRFs are identified correctly and are the ones you want to compare?
    I’ve done similar date-comparisons and it worked OK.
    Kind regards,

    Gerben Rienk Visser

    Van: [email protected] [mailto:[email protected]] Namens Christian ZIRBES
    Verzonden: donderdag 6 januari 2011 8:16
    Aan: [email protected]
    Onderwerp: Re: [Developers] Text area size

    Dear developers,

    I made one rule to compare two dates between two different visit (events) in my study.



    SE_VISIT3DAY141.F_PATIENTQUEST_506_V11.IG_PATIE_UNGROUPED_398.I_PATIE_SV3_QUEST_DT_2262


    This date must be greater then the date last visit




    Difference date
    SE_VISIT3DAY141.F_PATIENTQUEST_506_V11.IG_PATIE_UNGROUPED_398.I_PATIE_SV3_QUEST_DT_2262 gt SE_VISIT2DAY71.F_PATIENTQUEST_968_V11.IG_PATIE_UNGROUPED_398.I_PATIE_SV2_QUEST_DT_6253



    No invalid remarks, BUT it does not work!!

    Can anyone help me to compare two dates,
    Thanks in advance.

    Christian
  • zirbyclinicazirbyclinica Posts: 29
    Hi Gerber
    You were right, thanks.
    The problem comes from ItemGroups, same in both part of the expression.
    Thank you very much
    Best regards,
    Christian
    Le 11 janv. 2011 à 21:55, Gerben Rienk a écrit :
    > Hi Christian,
    >
    >
    >
    > Just to make sure I get this right:
    >
    > You want to compare two dates, on two different Events (SE_VISIT3DAY141 and SE_VISIT2DAY71).
    >
    > The dates are on on two different CRFs or CRF versions (F_PATIENTQUEST_506_V11 and F_PATIENTQUEST_968_V11)
    >
    > But the ItemGroups are on both CRFs are the same (IG_PATIE_UNGROUPED_398)
    >
    >
    >
    > Can you confirm this is right and that the CRFs are identified correctly and are the ones you want to compare?
    >
    > I’ve done similar date-comparisons and it worked OK.
    >
    > Kind regards,
    >
    >
    >
    > Gerben Rienk Visser
    >
    >
    >
    > Van: [email protected] [mailto:[email protected]] Namens Christian ZIRBES
    > Verzonden: donderdag 6 januari 2011 8:16
    > Aan: [email protected]
    > Onderwerp: Re: [Developers] Text area size
    >
    >
    >
    > Dear developers,
    >
    >
    >
    > I made one rule to compare two dates between two different visit (events) in my study.
    >
    >
    >
    >
    >
    >
    >
    > SE_VISIT3DAY141.F_PATIENTQUEST_506_V11.IG_PATIE_UNGROUPED_398.I_PATIE_SV3_QUEST_DT_2262
    >
    >
    >
    >
    >
    > This date must be greater then the date last visit
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > Difference date
    >
    > SE_VISIT3DAY141.F_PATIENTQUEST_506_V11.IG_PATIE_UNGROUPED_398.I_PATIE_SV3_QUEST_DT_2262 gt SE_VISIT2DAY71.F_PATIENTQUEST_968_V11.IG_PATIE_UNGROUPED_398.I_PATIE_SV2_QUEST_DT_6253
    >
    >
    >
    >
    >
    >
    >
    > No invalid remarks, BUT it does not work!!
    >
    >
    >
    > Can anyone help me to compare two dates,
    >
    > Thanks in advance.
    >
    >
    >
    > Christian
    >
  • David - I cannot answer specifically for OpenClinica, but often EDC solutions limit the standard field size to 255 characters in order to support legacy SAS. Prior to V6 I believe it had a 255 limit. To avoid this, EDC solutions implemented a separate Long Text field separately ensuring that it was only these fields that required special handling when data was pulled out the DB to SAS.
    Today though, I am not aware of a good reason for the limit.
    Doug
    On 4 January 2011 11:35, David S Hunnisett wrote:
    Hi all
    After further digging I can see that the limitation is hard coded in a lot of places and that openclinica is using the varchar(n) data format where n is typically 255.
    Is there any reason to limit data entry to 255 characters for any field ?
    the native storage in postgres is pretty much unlimited and even oracle can manage 4000 characters.
    http://www.postgresql.org/docs/9.0/interactive/datatype-character.html
    Thanks David
    > The text area size is limited (according to the docs) to 255 characters Is there any way to increase this to unlimited
    > (i.e. the text datatype in postgres) ?
    >
    > Thanks David
    >
    >
    >
  • davehdaveh Posts: 7
    Thanks Doug
    Its a bit of a problem for us, Macro has the same problem. Every study wants to use more characters.
    It would be a good one to remove and not too tricky either
    Step one make 255 a global constant.
    Step two alter database to set all to 4000
    Step three change constant
    David
    On 13 Jan 2011, at 18:03, Doug Bain wrote:
    > > David - I cannot answer specifically for OpenClinica, but often EDC solutions limit the standard field size to 255 characters in order to support legacy SAS. Prior to V6 I believe it had a 255 limit. To avoid this, EDC solutions implemented a separate Long Text field separately ensuring that it was only these fields that required special handling when data was pulled out the DB to SAS.
    > >
    > > Today though, I am not aware of a good reason for the limit.
    > >
    > > Doug
    > >
    > > On 4 January 2011 11:35, David S Hunnisett wrote:
    > > Hi all
    > > After further digging I can see that the limitation is hard coded in a lot of places and that openclinica is using the varchar(n) data format where n is typically 255.
    > > Is there any reason to limit data entry to 255 characters for any field ?
    > > the native storage in postgres is pretty much unlimited and even oracle can manage 4000 characters.
    > >
    > > http://www.postgresql.org/docs/9.0/interactive/datatype-character.html
    > >
    > >
    > >
    > > Thanks David
    > >
    > >
    > >
    >> >> The text area size is limited (according to the docs) to 255 characters Is there any way to increase this to unlimited
    >> >> (i.e. the text datatype in postgres) ?
    >> >>
    >> >> Thanks David
    >> >>
    >> >>
    >> >>
  • I think you also need to add a requirement to test every instance where a
    Text field of 4000chrs appears.
    The UI for general text entry will not work for 4000 characters - the
    scrolling makes it unusable. If OpenClinica was enhanced to offer 2
    controls - a long text control and a regular fill-in then that will work.
    You also need to consider how reports and data extracts will operate with
    fields extending out to 4000chrs. From a tools perspective, you want to
    ensure that if the tool is used to its capacity, that it will function
    correctly. Data entry, reporting and Data extracts.

    --
  • Cal CollinsCal Collins Posts: 111
    FYI there are a few older threads related to the 255 char limit
    discussion. Paul and I just touched base on this issue and we'll work
    some of these suggestions into version 3.1 - one of us will follow up
    soon with specific ideas for changes.
    http://www.openclinica.org/pipermail/users/2010-April/003592.html
    http://www.openclinica.org/pipermail/users/2009-December/002663.html
    http://www.openclinica.org/pipermail/developers/2009-February/000632.htm
    l
    Currently you can 'trick' the system into accepting > 255 (up to 4000)
    chars by adding a discrepancy note. You can also use the annotation note
    type to capture the additional information, though until 3.1 is out it
    is hard to get this annotation data out in extracts and reports.
    Cal

    -----Original Message-----
    [mailto:[email protected]] On Behalf Of Douglas Bain
    Sent: Friday, January 14, 2011 7:45 AM
    To: [email protected]
    Subject: Re: [Developers] Text area size
    I think you also need to add a requirement to test every instance where
    a
    Text field of 4000chrs appears.
    The UI for general text entry will not work for 4000 characters - the
    scrolling makes it unusable. If OpenClinica was enhanced to offer 2
    controls - a long text control and a regular fill-in then that will
    work.
    You also need to consider how reports and data extracts will operate
    with
    fields extending out to 4000chrs. From a tools perspective, you want to
    ensure that if the tool is used to its capacity, that it will function
    correctly. Data entry, reporting and Data extracts.

    --
This discussion has been closed.