December 3, 2020

Who DAT!? – “Tips from the Trainers” Series

Much to my wife’s (and other Saints fans’) disappointment, this post is not about football.  No, it’s about DAT files, the standard type of load file that is created from some legal review applications – such as Relativity and Concordance. In the past, Summation users who were on the receiving end of these files would have to send them out, or use some tool to convert them into DII files, the standard load file used by Summation.

Of course, now that Summation includes an option to import Concordance/Relativity files in the import wizard, that’s no longer necessary. In fact, Summation can import DAT files without users having to do all that much work. However, if you’re not familiar with how DAT files work and the kinds of data that might be in them, read on to find out how easy it is to deal with them using the new Summation.

First, you choose the Concordance/Relativity file type option in the Import Wizard:


Then a second box – Image Type – becomes available. This exists because DAT files typically load data, but not images, into the fields of a database. Images are instead loaded from either an OPT or LFP file, so to successfully load documents into your review platform, you need both.

As far as what those files contain, you do need to take a look at them first to make sure some things are correct. For example, in the OPT or LFP file you need to confirm that the path to the images is correct.

In my example, the path to the image for the first line tells me where I should be looking for my images:


So, the images for this document should be in a folder named 000001\Images\000001. But where is that initial folder 000001? It should be in the same location as the OPT or LFP file – that’s where Summation will begin to look for the images.


You also have to consider the paths that might be in your DAT file. In a typical Concordance database for example, the full text or OCR text of your document and the link to a native document are in two separate fields. So when you load a Concordance file, there may be a path to the native file. You’ll want to make sure it’s located correctly – the same way that the images are. If the path to the text files is in the DAT field, you’ll do that as well. There is also the possibility that instead of having the path to the text, the DAT file will simply contain the text of the documents as well. It’s important to know if that is the case, so that you can instruct Summation properly.

This is a simple example of a DAT file with a link to the native file and a link to the text:


So, can we load this file as is? Not quite yet. The paths are correct, the 000001 folder is in the same location as our DAT file, but it is still using the default BEGDOC and ENDOC fields from Concordance, and Summation will be expecting a DOCID field. Simple enough, let’s edit the DAT file using your favorite text editor, changing the BEGDOC field, to DOCID.


Now, we’re ready.

The last step is going to be to map the fields from our DAT file into Summation. Because Summation does not have a field  to populate a link to the native documents, nor or a database field that holds text, we’ll need to guide Summation to those fields in our DAT file. In the Map Fields box, Summation will ask us to map those fields while choosing the options that tell Summation what to do with the fields.


Here we’re using the NativeFilePath and Ocrfilepath entries in our Map Fields dialog to instruct Summation to treat those fields as the place to load the native document and the text of a document, the same way we would use the EDOC and FULLTEXT tokens in a DII.

If your DAT file has the actual text instead of a path to the text files, naturally, you wouldn’t use the Ocrfilepath as the field to map to. You would use the FullTextOnly field. That tells Summation to treat the contents of this field as the text of the document.

So there you go.  With this understanding, you should be able to load those files yourself and save some time trying to get them converted. Now what other litigation support software not only lets you export other platforms’ load files without hassle, but now lets you import them too?

Perhaps with that extra time, you can catch a bit more football this weekend.


Mike McBride

Mike McBride is a Litigation Support Trainer for AccessData Group and is responsible for helping develop and present AccessData Litigation Support training curricula. Mike spent 10 years working in the IT field, the last two doing tech support at the law firm of Bricker & Eckler, LLP in Columbus, Ohio. While at Bricker, he was given an opportunity to move into the Litigation Support department and has never looked back. He was eventually named manager of the department at Bricker before the call of the South, and an offer from Ogletree Deakins, led him to move to Greenville, SC, where he now resides. Mike is a Trial Director and Summation certified trainer, and has experience in all areas of law firm litigation and trial support. He has had several speaking engagements at the annual ILTA Conference as well as local events and has been blogging since 2001.

More Posts

Speak Your Mind