April 25, 2008 at 6:20 am
I agree that there're a lot of things, like this conversion, that should be done in the GUI instead of SQL Server. Displaying commas in dollar amounts and formatting dates and the like qualify, as well. That does two very good things... it distributes the "extra" clock cycles to the GUI thereby taking some of the load off of the server and it allows the GUI to format according to regional settings...
... if you have a GUI.
If all you have is batch code, then finding a good high speed answer in T-SQL is worth it. And, no, CLR's aren't the Nirvana of code that everyone is looking for, either. Source code external to the Server must be maintained and they ususally can't beat a properly written solution in T-SQL. Matt Miller, me, and a couple of other folks did some pretty heavy testing against CLR's and the only one that came out better was a RegEx CLR that did replacements (I can't put my hands on the URLs... I'd have to do a search). Of course, just because someone says something like this doesn't mean you shouldn't also do some tests of your own for you own particular situation.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 27, 2008 at 2:12 pm
Agree that presentation software is great for presenting end results data, but in some instances you want to have pre-filtered the results from your database via the underlying SQL. This was why I needed the conversion in the SQL, as I had to filter my table to get just a few rows out of a much larger table, and just present these few rows by the presentation software. I believe doing the filtering in the SQL on the server to be a lot quicker than passing the whole table back to the presentation software to filter it there. Thanks for the feedback.
Viewing 2 posts - 31 through 31 (of 31 total)
You must be logged in to reply to this topic. Login to reply