|
-
October 11th, 2009, 07:00 PM
#1
Allowing Key Changes To DB without duplicates
In an app I am working on, on some of the forms I would like to allow the user to be able to change the values of fields that are part of a unique constraint in the database.
for example one of my forms allows a user to change the part numbers in a parts list. the part number has a unique constraint in the database.
With this being the case the user could possibly swap the part numbers of two records like so:
Old | New
Part A | Part C
Part B | Part B
Part C | Part A
So when the user commits his changes to the database, the database would throw an exception when trying to update Part A to Part C because PartC would be duplicated.
With that being said, I have come up with the following solution, which will work, but seems so cumbersome and I was wandering if anyone had a more elegant solution:
So here is the process I came up with:
1) In the objects I use to store the partnumbers I keep track of the original partnumbers
2) When the user commits their changes I extract the list of objects that have partnumbers that are different from the original
3) with the list I match up objects where there is a match between a new and old partnumber - this is marked as an update
4) for new partnumbers with no matching old partnumber - this is marked as an insert
5) for old partnumbers with no matching new partnumber - this is marked as a deletion
6) Then I group all the pairs of objects into groups with old or new partnumbers that are relative to each other so that I can wrap the database
commit into a transaction
To illustrate:
this is what the user would see, they start out with the old values and end up with new values:
To the user, it simply appears as if they are updating the partnumbers:
Old | New
Part A | Part B
Part B | Part C
Part C | Part Z
Part D | Part A
Part E | Part E
with my procedure this is what actually happens
Old | New
Part A | Part A (update with Part D's fields)
part B | Part B (update with Part A's fields)
Part C | Part C (update with Part B's fields)
Part D | no match (delete this part)
Part E | no change
no match| Part Z (insert this part)
In this example all except for Part E would be wrapped in a transaction before updating to prevent any unexpected results.
Doing all of this achieves my goal of allowing the user to "update" the part numbers, but it requires a lot of processing and I thought someone else may have come up with a
better solution. thanks for any ideas
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|