Viewing 15 posts - 48,796 through 48,810 (of 59,099 total)
senthilkumar.v (8/13/2008)
select convert(char(4),datename(yyyy,'01/01/2008'))+convert(char(2),datepart (wk,'01/01/2008'))
Perfect... :hehe: Now, try that against Jenny's original request below... 😉
DECLARE @Serial CHAR(12)
SET @Serial = 'SER074400001'
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2008 at 5:55 pm
Sara_DBA (8/13/2008)
SELECT CONVERT(VARCHAR,GetDate(),112) 😛
Heh...ok, Sara... if you read Jenny's original request, tell me how your code converts the following, posted in that original request, to a date. 😛
DECLARE @Serial...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2008 at 5:53 pm
Heh... did they also happen to have all the data in a single EAV table? 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2008 at 5:49 pm
Heather (8/9/2008)
This makes sense for a reporting purposes, but why would someone do this for two operational databases?
Physical security, performance enhanced by having two boxes instead of just 1, different...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 10:20 pm
rosh (8/12/2008)
And in terms of performance?
Like everything else, it depends... how are the underlying tables index and does the query use them? What size is TempDB and will it...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 10:07 pm
rbarryyoung (8/12/2008)
I ask because those UPPER functions on your joins are likely killing any chance of using the indexes.
Heh... good thing the OP ignored your original suggestion right up to...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 10:03 pm
Heh... glad to see a kindred spirit.:)
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 9:54 pm
True enough... but my big question would be, why would anyone store HTML in a database?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 8:25 pm
I missed this article when it was first published... Nicely done Jacob! Not only was it a good article, but the followup posts are great, as well. You...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 8:15 pm
Heh... only every other Tuesday. 😛
What is the basis of your Bi-Temporal design?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 8:03 pm
I'd question the database designer as to why decimal values were stored as strings to begin with.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 7:59 pm
OR!... you can simply concatenate the values together in a nice long string up to VARCHAR(8000) in SQL Server 2000... see the following link for both the method and some...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 7:52 pm
No... it should be ok.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 7:48 pm
Haven't tested it because no data... but this should work SELECT ID, Name,
CASE SUM(Revenue)
...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 7:40 pm
helloanam (8/12/2008)
The columns in...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2008 at 7:20 pm
Viewing 15 posts - 48,796 through 48,810 (of 59,099 total)