May 3, 2012 at 1:09 pm
What do you think, you like it?
May 3, 2012 at 1:13 pm
Ok i read your comment now, then the firts version i wrote is ok, i just allows up steps. I just accepts Single, Married, (Divorced or Widowed). i does not accept changes in the same level, divorced to widowed, nor back steps married to single.
May 3, 2012 at 1:20 pm
adrian.facio (5/3/2012)
Ok i read your comment now, then the firts version i wrote is ok, i just allows up steps. I just accepts Single, Married, (Divorced or Widowed). i does not accept changes in the same level, divorced to widowed, nor back steps married to single.
But based on the OP's own definition of Single(1), Married(2), Widowed(3), Divorced(4); going from Widowed to Divorced would be a legal change. You could not, however, go from Divorced to Widowed.
May 3, 2012 at 1:31 pm
Well, i just did not tougth that "Widowed To Divorced" could be ok, i think i made my conclusion there, if you guys feel this change is ok, then the query i wrote is not suitable for the problem, but can still change StatusSequenceNumber, and it migth work.
May 3, 2012 at 1:33 pm
adrian.facio (5/3/2012)
Well, i just did not tougth that "Widowed To Divorced" could be ok, i think i made my conclusion there, if you guys feel this change is ok, then the query i wrote is not suitable for the problem, but can still change StatusSequenceNumber, and it migth work.
Not my call. I think you should be able to go from Divorced to Married, but after the thrashing (not really that bad) from the OP, my code won't allow ANY backward movement down the chain of Marital Statuses defined by the OP.
May 4, 2012 at 6:03 am
@adrian.facio
The problem is that for employee 4 keeps the original status "Widowed" and not the last status "Single" as your example suggest. How is that you know that New Status Single is the right one? It could be that the employee was indeed originally widowed and the new status change to "Single" is that one that is incorrect. How can we stablish a consistent rule to know what are the incorrect status changes?. The query i just wrote is based on the idea that the very first status recorded is always correct, and the cause of error migth be placed in newer status changes, it provides good consistency, but how can we adapt this to meet your needs?
My understanding with this sample data is like ....
whenever employees' status gets changed, a new record will be added and status change date will be the date when it gets changed. The first record of every employee is based on what was employee's status on the date of joining. So I hope this logical order now make some sense to you.
Dear members,
Yes i understand and agree that numerous status possibilities are there. however question is not data logic or logical sequence. As i mentioned earlier, that i have prepared this data set and i have prepared this just to map it with my actual and real problem - which some time hard to explain and sometime not allowed legally.
Note: I have given my solution in the very first post. And the purpose was that i have already achieved the desired results with some logic but i want you guys to give me some different thought, HOW TO IMPROVE this deletion without deviating from provided data set.
Focused, Simple, straight and precise delete query, as i have provided already. I hope i have further clarified my question.
I highly appreciate the thoughts and solutions of "Lynn" and "adrian" and all those who at least read this post.
Thanks folks.
Cheers.
May 4, 2012 at 7:03 am
Understood.
May 4, 2012 at 7:04 am
w
May 4, 2012 at 7:37 am
Oh NO. Please don't tell me you are shocked. 😀
May 4, 2012 at 7:40 am
iBar (5/4/2012)
Oh NO. Please don't tell me you are shocked. 😀
Nope
Viewing 10 posts - 31 through 39 (of 39 total)
You must be logged in to reply to this topic. Login to reply