How to Create Huge Problems With Your LabWare and Other Systems

The conversation

4 comments from 2 people on May 6, 2016. Gloria replied 2 times.

1. May 6, 2016

   John Newtown

   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.

2. Gloria MetrickAuthor

   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.

3. Fran Gomez

   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.

4. Gloria MetrickAuthor

   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.

Comments are closed. This conversation is from 2016. Ask us to remove a comment