Today brings you another installment of keyword search terms used to find my blog that I have decided to blog on. Yesterday, I noticed the search term “labware lims sql code” and couldn’t pass on talking about that.
Using LabWare LIMS SQL
If you’re looking to use SQL Code in your LabWare LIMS, be frugal about it. If you’re new to the system, just know that there are many features that will get and update data for you. You need to focus on learning those. There are also tools for updating records with the system’s programming language.
Overall, you should avoid updating, deleting or inserting records using direct LabWare LIMS SQL commands. It might execute faster, but you’re then overriding all the things that the system is doing for you, such as security checks, auditing, etc…
It’s Not Just About LabWare’s LIMS / ELN Nor About Regulations
Then, what LabWare LIMS SQL is allowed? Some projects completely disallow the use of any but the SQL SELECT command. Others allow them only for extremely limited cases. This is not just true of the regulated systems. Many systems do not want to lose their ability to track audits, manage security, etc… by doing something like this that steps outside the system’s boundaries. Here at GeoMetrick Enterprises, you can count on us not to step outside these boundaries. Read why at “LabWare LIMS: We’re the Experts.”
By the way, this is true of many of the products out there. It’s true that you want to be cautious about using SQL statements injudiciously. You should be extremely cautious about directly applying SQL commands to any of your systems. This is true whether it’s a LIMS, ELN, SDMS, CDS, etc…
As a Developer in a Development system, I need to create good test data. To do this, I do sometimes adjust data by directly doing a SQL UPDATE outside of the LIMS. So, this LabWare LIMS SQL application is outside what a Production system is doing. Developers get tools to do these tasks, so don’t be surprised if this isn’t something most people have access to. But as a develop is often creating new fields and tables to create new features, it sometimes means there is no mechanism in the current system to change these fields until you build it. So, to start out, I need to create some in order to create test data.
BUT!!!! I have known of people to be a little careless and goof-up everyone’s data in the Development system by making careless UPDATEs. AND for those people new to SQL, it’s not that hard to royally mess-up the Development database data by doing this.
With all that said, the Development environment is a place where this is acceptable when people are careful and know what they’re doing. Allowing people to do this in their Production system is unthinkable.
Side note: Yet another option is to have a personal database copy to work on so that the main Development system isn’t contaminated with erroneous SQL commands. Whether this is possible partly depends on the type of license in effect.
A Rare Exception
There are rare times when a bug causes the Production data to be wrong in some way that can be easily fixed by a LabWare LIMS SQL UPDATE. Some companies allow for a change control mechanism where the exact statement is written up and approved by a number of people before someone like a system administrator is allowed to actually run the update. It is a rare case and is heavily controlled.
Notice I haven’t mentioned that you can recover from a LabWare LIMS SQL UPDATE/DELETE/INSERT mistakes by bringing up your backup. It’s not just you who might have been adding data and programs since the last backup. They all need to keep working. They need and want to keep working on what they’ve already built. It’s not going to help them if they have to stop what they’re doing and wait for the backup restoration. So, don’t be too casual in your dependence on your backup system when you’re thinking about these issues.