Mamlin:
Sorry, I did not mean to undermine your post, just wanted to provide another alternative. It it just that I did not see the CREATE PROC in yours so I decided to post the full code I had. I did not review the actual code logic, so they may actually work in the same way (or be exactly the same).
Your suggestion to search for INTs is good, it is just that I never had to do that, or when I did, I pretty much knew what table to use. What I did do as an exercise as well as to help in a project I was doing was to write a .Net console app to basically implement the same generalized full DB string search logic but that would work against any database you can access via ADO.Net. Why you ask? Because I had to work with a third party (commercial) application developed in MS-Access that had a very horrible design, i.e. not normalized at all, used company names for links between tables, etc. I've been meaning to make this little app public but as usual, lack of time has prevented it. I just want to clean up the code a little bit.
And to expand on something I read in one of the posts, regarding SQL Injection. The little hack or "defacement" I actually experienced in my DNN 4.9.2 site was actually allowed by the DNN code, which is why it had to be fixed in 4.9.3. Don't get me wrong, I don't want to put down the Core Team, but the reality is that the DNN code allowed something that it shouldn't have. To be specific, it was allowing a user to enter text in any module that used the FCKEditor to enter code in the form <script>some malicious javascript</script>. Is that SQL Injection, well, not exactly because it is not injecting SQL code, it is injecting Javascript code. I do not know what would have happened if actual SQL code was attempted, probably wouldn't work because of the DAL/BLL architecture. Should this be something the module developers should take care of in the module code in the first place? I don't know, maybe.
Let me also expand on my site's defacement via Javascript. All the hacker was able to do was to enter JS code in the Guestbook that when loaded back to the browser would load an animated picture of a skull and bones from another site. I am not going to publish that code but it is very simple and I now use it for testing for this weakness on other sites. It looked scary but was very easy to clean up and the attacker had no access to modify the database directly, was not able to load any files to the server, and had no access to any of the DNN, SQL, or Windows accounts. I manage my own server and checked all these things carefully. To summarize, DNN is a very secure platform, remember that the server must be setup and managed with best security practices in mind as usual.
Carlos