Unfortunately this application doesn't work quite that simply. "Relativity" is an eDiscovery platform that allows users in the course of their work to add and remove fields that they believe are or are not relevant. These fields are all stored in this one table and can be added and removed as required. The problem is that during the course of adding and removing fields there is a exclusive lock held on the table.
I thought at first that using RCSI might help reduce the locking by reading data out of the version store while the DDL is running but that doesn't appear to be the case.
To that end we have had to create windows to enable these fields to be added and removed without disrupting work more than is necessary.
Does the software have an "oops" button that will allow the users to somehow recover a "field" (table column) that was accidentally removed because what they thought wasn't relevant suddenly turns out to be relevant? Or does it just "mark" the column as non-relevant without actually dropping it?
I agree with Brian... Reach out to the manufacturers of the "Relativity" product for help.
Shifting gears a bit, if the eDiscovery process you're using threads emails into a Parent-Child hierarchy to help you discover relevant, non-relevant, admissible, and "privileged" legs in an email chain by sampling/reviewing various "near leaf-level" and "near branch junction" documents, I know of some ways to do that faster than ever.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
"Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)