Multiple Runs In Close Proximity (Data Cross-Study Report Bleeding)

m Mike

on June 9, 2011

Hi,

We have Remote Desktops (RDPs) in which multiple users can run OpenCDISC from that single central connection. However, we’ve run into an issue where multiple users have run the process in close proximity (i.e. within seconds of one another), and some data from one study (e.g. Study A) has bled into the second studies (e.g. Study B) report.

I do know that OpenCDISC has the functionality to modify the outputted report name (i.e. Report Settings). Therefore, my question is as follows:

1) Are there limitations when not changing the Report Settings and starting the validation process in such close proximity across two (or more) users?

2) If the Report Settings are modified (i.e. the output name is different for each process), will this correct such an issue?

3) Are there limitations on how many unique processes can be run from a single install point (i.e. how many users are recommended)? Should there be minimum wait time prior to starting another process?

OpenCDISC Details:

Version = 1.2

Validate Data (option)

Standard = SDTM

Source Format = SAS Transport (XPORT)

Source Data = all in .xpt

Configuration = config-sdtm-3.1.2.xml

Define.xml = none

Report Format = Excel

RDP System Details:

MS Windows Server 2003 R2

Enterprise x64 Edition (SP2)

Forums: Troubleshooting and Problems

t Tim

on June 9, 2011

RE: Multiple Runs In Close Proximity (Data Cross-Study Report Bl

Hi,

You should be able to perform as many validations simultaneously as the underlying system can handle with respect to computing resources. In most cases, each user should be getting their own separate runtime process which will isolate the validations completely, so bleed-through should not be possible. If they are somehow running their validations in the same process, the Validator will still isolate the validations so that a collision of this nature cannot occur.

Looking at the code however, there's a fairly signficant bug that prevents the second case from being guaranteed 100% of the time. It does seem unlikely that your users would be able to trigger this condition, but it's not impossible. I'll go ahead and fix that issue in development for the next release, and I'll get back to you with what workarounds might be available. I do know that changing the Report Settings is unlikely to have an impact here, based upon what the problem appears to be.

Regards,
Tim

m Mike

on June 9, 2011

Hi Tim, Yes, we would usually

Hi Tim,

Yes, we would usually never run across such an issue, nor have during the many validations we've processed. However, it would seem the conditions were met for this scenario. We'll workaround this for the time being, and thank you for getting back to me so promptly.

Much appreciated!

Mike