Yesterday, I made a post regarding making sure that you don’t lose your LabWare static data. Here is that post: More on Not Losing LabWare Static Data. Since then, I noticed some links from another blog that had to do with lost and deleted data with the LabWare system.
In any case, this is something you need to pay particular attention to. There are a few layers to this. First of all, this is why I tell you that, once you get your system running that you should not be deleting data. If you delete a sample login template and then try to view or use samples that used that template, you will get an error. That is just one example. This is why you cannot merely delete data.
But then, you probably are about to realize that you cannot keep data, forever. Eventually, you have to archive some of it. What do you do, then, you are wondering? Well, that becomes a complicated thing to do. It’s not something I can answer in a few sentences. What it comes down to is this: you have to sit down and map out everything that has to get archived, together. Some data might end up in two places, depending what you’re doing with it. It’s a lot of work to do and you have to know what you’re doing to make it all work.
However, this is not something you have to address only with the LabWare LIMS but with many LIMS, ELNs, LES and other products on the market. You can’t just take data out of these systems without understanding what you’re doing.
The Final Question
Someone out there is now thinking this, “What if I mess up my system? What do I do, then?” Then, you have to fix it. Period. that’s what system administration is all about. Once in a while, you break it and, if you do, you’d better get cracking and figure out how to fix it before much time goes by.
Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/
I think it is important to point out that you can’t ‘delete’ data from the LabWare application. All transactions are recorded in the audit trail and can’t be changed or deleted. If you are inserting or deleting records directly from the RDBMS, you are following a practice that is not recommended by LabWare. It is also important to note that we wouldn’t recommend archiving static data records. The dynamic data in a production system will increase including your audit trail. LabWare provides functions for both Audit Archive and Dynamic Data Archive for this purpose.
This post suggests there are issues with losing static data in LabWare. That simply isn’t true and is a misleading presentation.
If you don’t know what you’re doing and you delete something then, yes, you have a problem with your system, LabWare, SampleManager or otherwise. You have to know what you’re doing. It’s not brand-specific and the issue has to do with the fact that if you have someone managing a system who doesn’t know how to manage it, you’re going to run into these problems.
But it’s easy to do. I could easily go into someone’s system, right now, and delete a bunch of data and they will have a problem. I wouldn’t do that because I know it would cause problems but I’m just saying it’s really easy to do with all these systems.
And we sometimes do it on purpose in our development systems just to clean them out. But when we know what we’re doing, it’s something we have to live with. In a production system or if you’re uncertain about what you’re doing, I’d refrain from this practice.
But I do want to stress that it actually is a good practice when you’re cleaning out a development system and it’s a controlled practice and you know what you’re doing. So, yes, there are a lot of “if”s in here.
I didn’t mean to make people afraid, just super-cautious.
In my opinion the title for this post and what explained are tightly separated, bad title for this topic, my honest opinion.
First of all, before the GoLive you have to tune your system and keep just what is required … that´s the first action. When the system grows up it is a great idea for archiving data … starting by the dynamic one, obviously.
Archive Static Data in Production? Does it make sense? Just when the business decides that existing template will not be needed anymore … it is not common but it´s an option after all. In this case what I suggest is the use of ‘mark as removed’ then the object can be restored in case it is required again or when users should open a sample logged using this template …. so an particularly in LabWare the scenario described in the post can be easily solved by using this Business Rule and that justifies when I said ‘bad title’ above … anyway …. creating a security group and assign the objects to this security group is another option .. in LabWare we can create configuration packages so we can move to a package all those static data objects and in case it is required then import them again, in other words, remove them from production with no export objects is not the way for who puts the best on what works.
The good idea from this topic is on advise the readers on try to not just focus the efforts on solving requirements day after day and try to put some activities on supporting a system once in production and try to keep it as tuned as possible.
Let me explain something for those who might not have realized the options going on with this discussion:
There is a flag that allows removed records to be either deleted or merely marked as “removed” but to still exist. It’s common when you first start out to set it to delete. As you play with the system, you can then easily get rid of the junk with the knowledge that old dynamic data that used these records will have errors. But the idea is that you then start “seriously” developing your system and not throwing things away, necessarily. And, just because you don’t throw it out (having the flag set to remove but not deleted) doesn’t mean that you’re required to move it from DEV to VAL/TEST or VAL/TEST to PROD, either.
But, in production, it’s not common to actually delete because the system is built on these static records. So, to stop using something, use the Remove function but have the business rule set to not delete.
Here’s a tip on these, though:
Regardless whether you merely mark a record as removed or have the business rule set to delete it, the audit records remain. So, if you accidentally delete someone’s record, you can merely re-add the name and you will be able to see the audits and recreate it. This is really easy for subroutines where you can just copy the code from the audit record right into the object.
Now, with that said, you shouldn’t be accidentally deleting other people’s records. But it does happen when people first start using the system ESPECIALLY with Explore Tables, which is why I remain conservative and use Manage Tables, which is much safer because you won’t be mistaken what record you’re on when you use Manage Tables.
[…] LabWare LIMS / ELN or even other brands of these systems. The last such post was poorly titled as How to Create Huge Problems With Your LabWare and Other Systems because it was more of a warning than a “how to” guide. Today, I will talk […]