In the past, I wrote a bit about how some of the LIMS tools can cause poor performance (Difference Between C# and VGL; LIMSBasic: A Programming Language). It’s possible to really slow-down the system if you’re not careful, and some systems and tools are much more sensitive than others. What’s a person to do?
For the inexperienced person, their first idea is to go around the system – to use any other tool that they can. Anything is faster. Using SQL commands or Visual Basic seems sensible – they’re just so much faster.
Don’t Do It!
Okay, seriously, it’s just so frustrating that these programs get so slow but you can’t just go out and use some other tool. When you do that, you’re often overriding security and the event triggers. You have to know the system you’re working with. So, by using an outside tool, you’ve sped up the programs and queries but you’ve also just bypassed all the things that you just spent a fortune to implement.
For example, with systems such as Thermo Scientific’s SampleManager LIMS /LES and the LabWare LIMS / ELN, one of the great features of them is that they’re database-independent. While some of the code might sit in a database field, it’s just sitting in there – the database isn’t doing anything but storing it. You can move to another database product and it won’t matter, as long as you haven’t built in any database-specific commands, basically.
Here’s my point: when you write a program in LIMSBasic, VGL or C#, for example, it’s the system – the base executable program – that’s enforcing all the security and causing the triggers to run. It’s not the database doing that. So, when you bypass the system by writing external programs and queries, nothing additional runs. You’ve gotten rid of all your security and all your triggers.
On the other hand, there are other types of systems which have their features built right into the database. You can use any program or query language you want with the and you still get all the features of them. However, you shouldn’t assume this is the case with the product you’re using. You need to verify this.
Bottom Line
We’ve all seen systems that had lots of charge time spent by people who get frustrated and write outside programs and queries THAT HAVE TO BE THROWN AWAY! That’s money right down the drain – it all has to be rewritten within the application tools. So, just be cautious before you even consider doing anything like this. If you’re new to it, don’t even try it.
Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/
Totally Agree, it is when the non-LIMS-culturized people have the perception that one result is just set the result field and forgot all the internal events fired in background to be coherent with the system itself (audit, statuses, check specs etc …).
At the same time, they are programmer techniques to be efficient when programming, it is not just cover the requirement, it is “cover the requirement being efficient, safety and stable” …. but it is like the marathon …. your goals are different depending on the stage you are, first of all your goal is finish the marathon then you can move your goal to something more ambitious like do it in one time, then less time etc …
Yes I agree with Gloria on this, it may be easier if you are new to development in either SampleManager or Labware LIMS and have experience in something else to write ‘outside’ the application, but it can have consequences. In regulated GxP environments this type of change that may bypass security or auditing is a big no, and it risks breaking the internal logic/rules that the LIMS uses that may result in quality/compliance issues. For applications like SampleManager where increments for tables are managed internally it can cause serious issues with key fields and for default values for records.
It is also the case that applications written outside of the LIMS become forgotten after a while especially if people move on. And I have come across cases where the original source files have been ‘lost’ so making changes to these becomes difficult to say the least.
[…] Programming Around Your System […]
[…] Programming Around Your System from November 18, 2015 […]