Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Concatenate, compare and delete!
- Thread starter Steve1445
- Start date
MichaelRed
Programmer
Hmmmmmmmm,
Step one. Select the 'survivor' table, and add the seventh field to it.
Step two, use the 'Wizzard' of duplicate records to identify the semi-duplications.
Step three. Use the FInd Dups query as the source for an append query to populate the new field in the survivor table.
Step four. Create an "UnMatched" quewry (anonther one of Merlin's hebchmen). This should "find" all the records in te NON-Survivor table which are not in the Survivor table.
Step five. Append the Unmatched records to the Survivor table.
Step Six. Delete the Dups Query and the UnMatched Query.
Step Seven. Rename the NON-Survivor table.
Step eight. Change all references to the NON-Survivor table to the Survivor table.
Step nine. Run Extensive tests and find LOTS more references to the NO)N-Survivor table.
Step Ten. Buy Bullet proof Vest, Cubicle walls, and an armoured SUV. You will need these when the Users start logging in and finding what ELSE you did not adequatly test.
Step eleven. Update your resume.
Step twelve. See if the org will 'spring for "speed Ferret", or some equivalent.
Step Twelve A. (the Yes Part). Buy it. Use it to -AGAIN attempt to replace all occurances of NON-Survivor to Survivor.
Step Twelve B. (the No Part). Let me know where you were employed.
Step thirteen. Contact your favorite employment agenc[y | ies].
Feel free to re-arrange steps ten through the remainder (13) in, above and /or around the first nine.
If it is a very small db with only a couple of users, you may actually accomplish this with little angst. If it is a large multi-user data base which is 'important' to your company, I would ONLY attempt this by creating a Test db (FRONT END AND BACK END!) and incorporating the real programatic steps (except the deletion of the temporary queries) in a procedure. Get your boss to approve of the change - IN ADVANCE - and get some 'power user' to agree to TEST the modified db through a set of scenarios/transaction which thoroughly exercice the db. Get the Speed Ferret program to do the replacement of the table names.
After the TEST db is 'approved' copy the module to the production db. KICK EVERYBODY off. Get exclusive access to the db. Run the procedure. Have POWER USER run all (or at least many / most) of the tests. Correct any problems. Let the universe back on. Keep steps 10 through 13 firmly in mind.
MichaelRed
mred@att.net
There is never time to do it right but there is always time to do it over
Step one. Select the 'survivor' table, and add the seventh field to it.
Step two, use the 'Wizzard' of duplicate records to identify the semi-duplications.
Step three. Use the FInd Dups query as the source for an append query to populate the new field in the survivor table.
Step four. Create an "UnMatched" quewry (anonther one of Merlin's hebchmen). This should "find" all the records in te NON-Survivor table which are not in the Survivor table.
Step five. Append the Unmatched records to the Survivor table.
Step Six. Delete the Dups Query and the UnMatched Query.
Step Seven. Rename the NON-Survivor table.
Step eight. Change all references to the NON-Survivor table to the Survivor table.
Step nine. Run Extensive tests and find LOTS more references to the NO)N-Survivor table.
Step Ten. Buy Bullet proof Vest, Cubicle walls, and an armoured SUV. You will need these when the Users start logging in and finding what ELSE you did not adequatly test.
Step eleven. Update your resume.
Step twelve. See if the org will 'spring for "speed Ferret", or some equivalent.
Step Twelve A. (the Yes Part). Buy it. Use it to -AGAIN attempt to replace all occurances of NON-Survivor to Survivor.
Step Twelve B. (the No Part). Let me know where you were employed.
Step thirteen. Contact your favorite employment agenc[y | ies].
Feel free to re-arrange steps ten through the remainder (13) in, above and /or around the first nine.
If it is a very small db with only a couple of users, you may actually accomplish this with little angst. If it is a large multi-user data base which is 'important' to your company, I would ONLY attempt this by creating a Test db (FRONT END AND BACK END!) and incorporating the real programatic steps (except the deletion of the temporary queries) in a procedure. Get your boss to approve of the change - IN ADVANCE - and get some 'power user' to agree to TEST the modified db through a set of scenarios/transaction which thoroughly exercice the db. Get the Speed Ferret program to do the replacement of the table names.
After the TEST db is 'approved' copy the module to the production db. KICK EVERYBODY off. Get exclusive access to the db. Run the procedure. Have POWER USER run all (or at least many / most) of the tests. Correct any problems. Let the universe back on. Keep steps 10 through 13 firmly in mind.
MichaelRed
mred@att.net
There is never time to do it right but there is always time to do it over
- Status
Similar threads
- Locked
- Question
