This error occurs during a COC update.  It is caused when a connection between the software and the database gets closed prematurely.  It appears to be a problem with the application server (Tomcat).  We are publishing some new code tonight (Dec 6) that will reduce (not eliminate, but reduce) the number of times it happens.  Technically, its not a problem with NeoNexus code, but a problem with the Tomcat connection pool manager (sort of like a bug in Microsoft Access software straight out of the box from Microsoft).  We are searching for a way to deal with it.

In the meantime, when that happens, you have to click on the COC item in the left menu, search for the COC you were just working on, and go back to it again.   The good news is that the updates seem to occur; you just have to go back to the COC to view the changes.

Sorry for your pain. IF you can figure out a sequence of events that triggers this error consistently, please let me know (I’ll send you a bonus gift!).  The frustrating part so far is it seems to happen randomly, so it is harder to track down.

Since there are many reasons that lab analysis on a sample must be performed more than once, the HiveMind EDD format allows a laboratory to report multiple runs for a sample.  This is done using the test types “initial”, “reanalysis”, and “reextract”.  All samples use the “initial” if they are only run once, and then additional runs are reporting using the test types “reanalysis” and “reextract”, depending on whether extraction was done a second time or not.   If you have 10 analytes to report, then all 10 analytes should be reported for each and every run (initial, reanalysis, reextract). This is discussed in the HiveMind manual.

However, the issue of metals was not covered in the manual even though it was taken care of in the programming.  With ICP metals, multiple runs do occur, but a result is not generated for each run, so you cannot report every analyte for every test run.  We handle this through a test type called “reinitial”.  The way reinitial works, you report the runs separately in the test file, but you can include only one result for multiple runs in the result file.

Example:

Test File
“COBB-BD020-65001″,”SW6010_AQ_D”,”05/29/2007″,”21:04″,”D”,”NA”,”initial”,”,…
“COBB-BD020-65001″,”SW6010_AQ_D”,”05/31/2007″,”12:33″,”D”,”NA”,”reinitial”,…

Result File
“COBB-BD020-65001″,”SW6010_AQ_D”,”05/29/2007″,”21:04″,”D”,”NA”,”initial”,”7439-89-6″,”IRON”,89.2,,”TRG”,…
“COBB-BD020-65001″,”SW6010_AQ_D”,”05/31/2007″,”12:33″,”D”,”NA”,”reinitial”,”7439-96-5″,”MANGANESE”,8.84,,”TRG”,…

In this case, iron passed the first time, but manganese failed and was rerun.  Your test files includes two runs, but iron and manganese are only listed once each in the result file.

To compare, if this was run for BTEX, it would look like this:

Test File
“COBB-BD020-65001″,”SW8260_AQ”,”05/29/2007″,”21:04″,”D”,”NA”,”initial”,”,…
“COBB-BD020-65001″,”SW8260_AQ”,”05/31/2007″,”12:33″,”D”,”NA”,”reanalysis”,…

Result File
“COBB-BD020-65001″,”SW8260_AQ”,”05/29/2007″,”21:04″,”D”,”NA”,”initial”,”1330-20-7″,”XYLENE (TOTAL)”,420,…
“COBB-BD020-65001″,”SW8260_AQ”,”05/29/2007″,”21:04″,”D”,”NA”,”initial”,”71-43-2″,”BENZENE”,4000,…
“COBB-BD020-65001″,”SW8260_AQ”,”05/29/2007″,”21:04″,”D”,”NA”,”initial”,”100-41-4″,”ETHYLBENZENE”,140,…
“COBB-BD020-65001″,”SW8260_AQ”,”05/29/2007″,”21:04″,”D”,”NA”,”initial”,”108-88-3″,”TOLUENE”,34,…
“COBB-BD020-65001″,”SW8260_AQ”,”05/31/2007″,”12:33″,”D”,”NA”,”reanalysis”,”1330-20-7″,”XYLENE (TOTAL)”,425,…
“COBB-BD020-65001″,”SW8260_AQ”,”05/31/2007″,”12:33″,”D”,”NA”,”reanalysis”,”71-43-2″,”BENZENE”,3503,…
“COBB-BD020-65001″,”SW8260_AQ”,”05/31/2007″,”12:33″,”D”,”NA”,”reanalysis”,”100-41-4″,”ETHYLBENZENE”,154,,…
“COBB-BD020-65001″,”SW8260_AQ”,”05/31/2007″,”12:33″,”D”,”NA”,”reanalysis”,”108-88-3″,”TOLUENE”,10,…

As you can see, the primary difference between “reinitial” and “reanalysis” is that if you use a test_type of “reanalysis”, then you must report a result for every analyte for EVERY run.  If you use “reinitial”, then only one analyte is reported for multiple runs.

When a laboratory delivers an EDD, the EDD file naming structure is based on the SDG/Group number. The web code uses this SDG/Group number to match the EDD to the correct Chain of Custody (COC).

However, when the consultant creates a COC, the SDG number is empty because it does not exist yet. In order for the EDD to load, the SDG must be assigned to the COC prior to attempting to load the EDD.
At this time, either a laboratory or a consultant can assign the SDG number. You do it by searching for the COC and adding it to the SDG/Group # file, and then clicking “Update”