With the new budget year starting for many companies, many of you will be starting new projects. Some of these will be LabWare LIMS / ELN projects. The number one thing to tell you is to set yourself up for success – don’t lose your static data, which 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 around, there are times when they don’t necessarily communicate these issues in a manner that you might remember. This post is part of my work to encourage creating better practices in this New Year.
The best way to keep from losing your static data is to hire a fantastic and awesome LabWare LIMS / ELN consulting company such as GeoMetrick Enterprises, who will guide you toward healthy data-saving practices. 😉 (Notice that I retain my sense of humor as we’re early in the new year!).
The Technical Details That You Were Hoping For
When you first start your system up, you will set your static data up so that, when you remove a record, that it will get deleted. You need to start this way. When you’re initially try out naming conventions and trying to figure out what direction to take, you’ll be creating a lot of junk. You’ll want to clean it out by using the Remove command.
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.
You can solve this 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 but will always know which one you’ve got open because the Remove you use will 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 a 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 do this 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 ELN
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 might be some hesitation to switch.
If you’re working in the ELN, you want to make sure you switch. There can sometimes be problems exporting/importing ELN workbook template as objects, which you don’t necessarily find out until you try to import.
Now, one warning, here – when you export an ELN workbook template as XML and import to another database, keep in-mind that if you’ve got the “step” functionality on one system and not the other, there’s probably no amount of fiddling with the XML file that will overcome this – you’ll have to have “steps” implemented in both.
One more gotcha – if you’re importing just a couple 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.
A few good habits in the beginning and you’ll get in the habit. 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!