I have decided to devote a tiny amount of energy toward helping others. While I tend to avoid giving product-specific tips, I decided to break that rule in order to share some tips with others. Today’s product – LabWare LIMS / ELN.
If you would like to read more about the LabWare LIMS / ELN and surrounding issues, read “LabWare LIMS: We’re The Experts.”
To those of you experts out there, you know there are things that people SHOULD know but don’t. There are certain issues and questions that tend to come up too regularly. With that in-mind, I thought if each person who sees this could share one good tip that it would help those out there who are on their own build better systems through better basic understanding.
Rather than getting into specific modules, such as the ELN, Stability Manager, or the like, the plan here is to try to give tips that are so basic that they can apply anywhere in the system.
To those who would read this, keep in-mind that this is not a support site. These tips are merely meant as potentially a useful collection of extra tips. All support should remain with the LabWare discussion groups or your consulting company’s internal discussion help groups.
I will begin with the first tip as a comment to this post but I welcome tips from all others who wish to share and encourage it. We complain so much about the silly things we see in the LIMS Basic and configurations, lets help others instead of complaining about them.
One Thought to “LabWare LIMS / ELN Tips”
Avoid using the Save() command when the system is in the middle of transaction.
There are many events in LabWare LIMS where you will need to add programming. When a person is new to this type of programming, they tend to throw the Save() command into their programming too casually.
The problem is that, when you do this, you interrupt the flow of the data being saved. You can actually cause data to be saved out of the order it’s needed in and can cause a variety of unintended consequences.
Then, when you realize you’ve got problems, you then address this by writing quite a lot of extra code in quite a few extra places.
Instead of all these problems and extra code, don’t put the Save() command in there in the first place – do what you can to use the context data.
You’re now about to ask for a list of places where you’re in the middle of a transaction. Forget it – don’t memorize these – I certainly don’t. If you memorize them, when you start using a new module, then you just need to potentially memorize more of them. Instead, whether you’re in the project manager automation, scripts, those for stability manager, or even the ELN, here’s the other part of my tip – read the name of the event , sit and think about whether you think you’re in the middle of a transaction. Get into this habit when you put code in any of these places and, eventually, it will be second nature to you whether you need to and/or should be using the Save() command or not.
One more tip from my own experience having used all the standard events in the system, over the years, as well as many of those in the extra modules: is that you have to be observant about where you’re at and what you’re doing a bit, here. You might want to turn on the debugger. Comparing the events for something like the analytical batch manager to the ELN, for example, can be a bit confusing to the novice as they both work rather differently, having different purposes. Saving is tricky because you not just want to avoid incorrect Save() usage, but certain modules depend on having saved objects to work on at different points than what other modules do.
If this seems confusing, just open the debugger and try it all – open a database window, too, and just watch things start to show up and change and you’ll probably find that helpful, as well.
Comments are closed.