Geez, that's a lot of busy work that should probably be handled by SSRS. You can do it in T-SQL, but there is a lot of overhead in formatting strings there instead of just returning the native data. Here is one way that yields 11/25/2013 3:03:12.567PM
:
SELECT CONVERT(CHAR(11), GETDATE(), 101)
+ LTRIM(RIGHT(CONVERT(CHAR(26), GETDATE(), 9), 14));
If you really need the space between the milliseconds and AM/PM, then you can get there with a little more work:
SELECT CONVERT(CHAR(11), GETDATE(), 101)
+ LTRIM(STUFF(RIGHT(CONVERT(CHAR(26), GETDATE(), 9), 14),13,0,' '));
And if you really need the leading 0, it gets even more fun:
SELECT CONVERT(CHAR(11), GETDATE(), 101)
+ RIGHT('0' + LTRIM(STUFF(RIGHT(CONVERT(CHAR(26), GETDATE(), 9), 14),13,0,' ')),15);
In SQL Server 2012, you'll be able to say:
SELECT FORMAT(GETDATE(), 'MM/dd/yyyy hh:mm:ss.fff tt');
But again, these methods of formatting strings in SQL Server force a lot of extra CPU overhead on the database that is much better handled by the presentation layer - which has to treat every row independently anyway. SQL Server only has to treat a set as a bunch of independent rows when you force it to, by applying formatting and other things, and this can slow the query down significantly.
Never mind that mm/dd/yyyy
is very irresponsible output. Are you sure your entire audience will always understand that 06/09/2013 is June 9th and not September 6th?