April 15, 2017 at 1:03 pm
Comments posted to this topic are about the item Find and Replace a value across all tables in database
April 28, 2017 at 9:45 am
Nice code.
Be good to point out that it only works only on complete column values not partial.
Also I have one enhancement.
It didn't work on one of my tables and I found out it was because the column Name was "To" for email values.
Change the EXEC line in the code to this:
EXEC ( 'Update '+@TableName+ ' Set ['+ @ColumnName+'] = '+''''+@ReplaceWith+''''+ ' Where ['+@ColumnName+'] = '+''''+@SearchThis+'''')
And it will work!
April 28, 2017 at 8:01 pm
jimmy.white 20227 - Friday, April 28, 2017 9:45 AMNice code.Be good to point out that it only works only on complete column values not partial.
Also I have one enhancement.
It didn't work on one of my tables and I found out it was because the column Name was "To" for email values.
Change the EXEC line in the code to this:EXEC ( 'Update '+@TableName+ ' Set ['+ @ColumnName+'] = '+''''+@ReplaceWith+''''+ ' Where ['+@ColumnName+'] = '+''''+@SearchThis+'''')
And it will work!
Thanks for pointing​ out.
April 29, 2017 at 4:03 pm
With absolutely no disrespect to the author, I cringe a bit when I see things like this. It generally means that the database wasn't properly designed to begin with. If it were, you'd likely only need to make a change in one column in a single row in a single table.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 30, 2017 at 11:30 am
Time to re visit the database design, normalisation wouldn't go amiss here.
The script itself uses 4 variables of 256 each but the dynamic sql variable is only 999 and mixing non Unicode and Unicode values!!
Do yourself a favour and don't run the script, re design your database instead
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 30, 2017 at 3:51 pm
After the loop, the first thing I noticed was the data type mismatch. That found not be fun.
That said, what Jeff and Perry said holds true. All that duplicated data means it's time to invest in a redesign.
April 30, 2017 at 10:51 pm
Jeff Moden - Saturday, April 29, 2017 4:03 PMWith absolutely no disrespect to the author, I cringe a bit when I see things like this. It generally means that the database wasn't properly designed to begin with. If it were, you'd likely only need to make a change in one column in a single row in a single table.
Thanks for your thoughts but we don't live in an ideal world. I joined the project during maintenance and enhancement phase, so I have to fix problems​.
May 1, 2017 at 1:39 pm
Devendra Thakur - Sunday, April 30, 2017 10:51 PMJeff Moden - Saturday, April 29, 2017 4:03 PMWith absolutely no disrespect to the author, I cringe a bit when I see things like this. It generally means that the database wasn't properly designed to begin with. If it were, you'd likely only need to make a change in one column in a single row in a single table.Thanks for your thoughts but we don't live in an ideal world. I joined the project during maintenance and enhancement phase, so I have to fix problems​.
Yup. That's why I said "With absolutely no disrespect to the author". This reminded me of the (now 3) times I've had to go through 600 or so tables to find all combinations of a ClientID and LoanNumber to change all of the loan numbers for a given client. Not only did they NOT use the LoanID that's contained in the loan table but they spelled "ClientID" and LoanNumber each a half dozen different ways, used leading zeros on some and not on other columns, used dashes on some and not other columns, and had 2 different meanings to "ClientID" types of columns and 3 different meanings for "LoanNumber" types of columns. What should have been a 1 minute change turned into a week's worth of research and tweaking even after I'd written the discovery code.
And, just like the people that wrote your less (whole lot less) than ideal database, it's actually too late to do anything about it (which would actually have some serious performance and DRI benefits, as well) because it would require a total rewrite of all GUI code, Batch Code, and even simple C.R.U.D... all because someone decided to not get someone who knew about databases until they were in the "maintenance and enhancement" phase. Oddly enough, if they had done it correctly to begin with, they wouldn't need much of such a phase.
At that's why I cringe every time I see scripts that need to do what you've necessarily had to do. Again, none of my cringing was directed at you. Your good article/code serves as, yet again, another good example of why treating the database as "just a place to store data" as an "after thought" is absolutely the wrong thing to do. It's more proof positive of the adage "If you want it real bad... that's the way you'll get it". 😉
Thanks for taking the time to write the article and share your code.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 21, 2017 at 7:14 am
Also with no disrespect to the author... it's not all tables in a database if you're only looking at one schema!
July 21, 2017 at 7:33 am
If you must do something like this, then at least automate it using a simple and tested script like the author provides. In the distant past, I've seen projects where they would allocate two or three coders working for a two weeks on a task like this... and then bill the poor client for XXX hours.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply