LabWare LIMS Static Data – Don’t Lose It!

Some of you will be starting new projects, this year. Some of these will be LabWare LIMS / ELN projects. The number one thing to do is to set yourself up for success. First of all, don’t lose your LabWare LIMS static data. This is easy to do when you’re first starting. This is especially true when you’re doing the project by training your internal staff and not using experienced resources for implementation. Even with experienced people, there are times when they don’t necessarily communicate these issues in a memorable manner.

Commercial Plug

The best way to keep from losing your LabWare LIMS / ELN static data is to hire an expert LabWare LIMS / ELN consulting company. Yes, I mean GeoMetrick Enterprises, who will guide you toward healthy data-saving practices.  😉 Here is a link where you can read more about what we know about the LabWare LIMS / ELN.

Accidental Deletion of LabWare LIMS Static Data

When you first start your system up, you will set your LabWare LIMS static data up to delete removed static records. You need to start this way. When you’re initially starting, you’ll be creating a lot of junk. You’ll want to clean it out by using the Remove command. So, you do initially want it set this way.

Unfortunately, you might also be using Explore Tables. When you first start using Explore Tables, you’re never quite certain where your cursor is at. It’s incredibly easy to Remove the wrong record. You’ll do it by accident and you won’t know what you just removed. Often, it’s someone else’s record so you won’t really know what’s missing.

Suggested Solutions

You can avoid losing LabWare LIMS static data by always using Manage Tables. In Manage Tables, you’ll never be in doubt of which record you’re on. Plus, Manage Tables is handy because you can open multiples and just stack them slightly overlapping each other. You’ll have many records open at once. However, you’ll always know which one you’re removing because you’ll be in the window of the record you’re looking at.

Another way to address this is, if you’ve done any amount of work, export it to your local drive. That way, if another team member accidentally removes your records (or if you yourself do it), you can just import it back to the system.

One more thing you can do is to turn on the auditor. Unfortunately, turning on the auditor will create a LOT of unwanted records that you’ll have to clean-out, and this is kind of a problem if you’re using a small database, but what people don’t initially realize is this – if you Remove (with delete business rule) a subroutine, you can re-add it by creating a new record with the same name. Then, the audits for that record will show up AND (here’s the great part), you can go into the auditor and copy-and-paste the code from the deleted record into your new record. Often, you’ll wait until you get your network database setup to turn on the auditor because it can handle the extra records from the auditor. This is one of many reasons why companies get antsy about getting their network database set up.

Specific Notes on Export/Import XML and the LabWare ELN Static Data

For years, LabWare has been telling us to stop using the Export/Import Object commands and to switch to Export/Import XML. But since the Objects worked fine and because that was already what people were using, there was hesitation to switch. LabWare LIMS static data is managed mainly as the LIMS data is, but with some additional challenges.

If you’re working in the ELN, you want to make sure you switch. There can sometimes be problems exporting/importing ELN workbook templates as objects. You don’t necessarily find this out until you try to import.

One more gotcha – if you’re importing just a few objects and you import, manually (not using Changes Manager, but the actual menu options in something like Manage Tables), do NOT open them up in between exporting – entirely leave them and come back if you want to check them.

If you’ve worked at all with the ELN, you already know that, when you open the workbook file, it thinks you’ve made a change whether or not you have. If you import a couple objects, then open one to check it, of course, it’s going to ask if you want to save the changes. But what you don’t realize is that it might be relying on the workbook file of the previously imported object, not the current one. This is hard to explain but you’ll have a real surprise when you come back to the objects. Seriously, don’t ever open them without entirely leaving the objects and coming back.

Backup

Let’s not forget backup. That’s a key to recovery that you must have if you want to maintain your LabWare LIMS static data.

The reason this comes up is that I ran into a situation where I exported the XML for an experiment workbook. Next, I made some changes. Then, when I tried to use the experiment workbook to create an experiment, it brought up an entirely different workbook format.

“No problem,” I thought, as I restored from the XML that I had saved. And, when I opened up the re-imported experiment workbook template, guess what….if you guessed that it was restored and I had that “ta da” moment, you’d be wrong! Instead, it was an entirely different template all together.

So, restoring from the XML didn’t do it, in this case. This is where having another backup was important.

Bottom Line

A few good habits in the beginning and you’ll get in the habit of carefully maintaining your LabWare LIMS static data. It’s not as hard as it sounds. But, as always, the intense configuration/programming tools we use in these big systems require more effort to manage than if we picked some tiny system with fewer options. Get into this mindset that many tools require more management effort and you’ll be fine. You got what you just paid a small fortune for, so it’s a good thing. Really!