I was showing a simple test for determining whether your record with TWO semi-independent flags are in a valid configuration. I wrote it as a response to those who complained about the complexity of the test. It's a freakin' one-liner test with two parameters. I agree it shouldn't be so hard as some folks are making it out to be.
Office VBA reference topic
learn.microsoft.com
You have to look at the truth-table for the IMP Boolean operator. In this table, you can test those two flags in a single statement to see if they are in a valid configuration. Per your discussion, the only invalid configuration is if both ACTIVE and TRASH are true at the same time. The expression I mentioned is a simple test for exactly that case. The ONLY invalid state for IMP is when the left operand is TRUE and the right operand is FALSE.
| ACTIVE | TRASH | NOT TRASH | ACTIVE IMP (NOT TRASH) |
| FALSE | FALSE | TRUE | TRUE |
| FALSE | TRUE | FALSE | TRUE |
| TRUE | FALSE | TRUE | TRUE |
| TRUE | TRUE | FALSE | FALSE |
I think I see the problem here. Businesses run by rules. It is not a state table it is a business decision. Active is a state. Trash is a state. Each of these are business decisions.
A paint color record is Active or Trash. Active means that we sell more than 10000 gallons a month. The president of the damned company decided this. Not some flunky in IT. We sell millions of gallons of white a month, we sell 5 gallons of that icky green color. We are not going to deal with a paint color where we only ever sold a five gallons. The business rule is that Active means historically we sold more than x gallons a month. A muckety muck makes that decision.
The business rule for deleting records: We have never ever sold that color. We never even produced it. EVER. Any paint color that was never even manufactured will be deleted. Somebody silly sales guy loved shades of green. He decided that we would have 10 THOUSAND colors of green. He lobbied persistently and got 10000 shades of green. Only 1 ever sold. We have 9,993 green color records where we have never sold a single gallon. We need to clean up our paint color tables. The president of the company makes that decision. Not some flunky in IT.
There are RULES for what defines Active. It is not a binary "related to Trash" thing.
There are RULES which define Trash. It is not a binary thing "related to Active"
This is not some foreign concept guys. Rules run businesses.
A client is active if he buys more that $10000 a year. It costs us $20,000 a year to even deal with a customer. We have people who process orders, who pick orders, who drive orders around. We lease office space for these workers. We are not dealing with customers who don't buy enough stuff from us. The president of the company issues an edict. "Make all customers who purchase below X dollars inactive. Send them a letter. Do not process any orders below $1000 for that customer. If they want to be active, then they will order a larger order."
The president of the company makes that BUSINESS decision, not some flunky in IT. Active is a state. In ANY TABLE it is a state. It is unrelated to trash, in ANY SENSE OTHER THAN a record cannot be active and trash at the same time.
An order was placed a month ago. It was an active order. We were working on it. The client came on hard times. They called up and asked us to place the order on hold. We make it inactive. We didn't trash it. A BUSINESS DECISION is made to make that order inactive. That client goes out of business. Hmmmm NOW we need to delete that order. It was never processed, it will never be processed. The PRESIDENT dictates that Inactive Orders, where we never heard from the client again will be deleted. A business decision. A muckety muck makes that decision, not some flunky in IT.
WE are flunkeys in IT. We do not decide that some state table defines active and trash. It is NOT a state table. It is TWO ENTIRELY UNRELATED STATES of whatever table it is in. Muckety mucks make decisions as to what these states actually mean and when each of these ENTIRELY UNRELATED states will change.
Go to Amazon. "This product is not currently active. We don't know if it will ever be sold again". It says that right on the product page on many different things. A BUSINESS DECISION somewhere out in the world, NOT A STATE TABLE!!!
If you want to make this silly argument that it is nothing more than a state table with the Muckety Mucks in your client's company then so be it. It is not my job to argue that. When the President tells you that HE makes these decisions and you need to go somewhere else...
Now that I am calm again (ahhhooooommmmm this is what I do for a living... Ahhhooooommmmm this is what I do for a living), Trash was a flag that I created out of thin air to trap the delete key and prevent order entry flunkies from deleting records. To prevent sales flunkies from deleting records. The records may in fact end up deleted. Or not. They might have been "deleted" by a flunky somewhere hitting delete. I created this flag because the IT department was complaining that they were having to restore backups too often because some flunky deleted stuff they shouldn't. In many if not most cases REAL DELETES should come from delete queries being executed because some muckety said to do so.
That doesn't change the fact that behind the scenes, BUSINESS DECISIONS made by muckety mucks drive these very real states.
I was oh so hoping that we could discuss the mechanics of classes implementing the trash flag, how events can enforce a rule. I guess not. Good luck with your state table. And so with that I am out of here.
