Viewing 15 posts - 58,696 through 58,710 (of 59,067 total)
IMHO, archiving data into separate monthly named databases is one of the worst things you could do... they (3rd party provider) did the same thing were I work and it's...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 21, 2005 at 11:48 pm
Does this do it for ya?
SELECT 'ID1' AS IDName, ID1 AS IDValue FROM yourtable
UNION ALL
SELECT 'ID2' AS IDName, ID2 AS IDValue FROM yourtable
UNION ALL
SELECT 'ID3' AS IDName, ID3...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 20, 2005 at 11:56 am
I know what you mean... It's only when they live up to the name of "BSOFH" and they've got that control thing going on... or, they're just plain old stupid.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 20, 2005 at 11:27 am
I gotta agree with THAT! Between a tally table (you guys call it a numbers table) and/or a date table (mine are combined into one which is why I called...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 19, 2005 at 9:35 pm
Cool... Thanks Noeld. It's been so long since I've used a trusted connection, I almost forgot they existed. ![]()
I'll probably keep using linked servers, though,...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 17, 2005 at 10:58 pm
One of the things I don't like about open row sets is the login information is in the query... and, no, I prefer not to encrypt queries especially on development...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 17, 2005 at 7:00 am
test
--Jeff Moden
Change is inevitable... Change for the better is not.
August 15, 2005 at 9:36 am
Reddy,
Thanks for the advice especially about the Repair_Allow_Data_Loss option... I'll remove that holding it for the very last stab.
Understood about the other stuff... I did try attaching in EM, using...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2005 at 4:32 am
Awesome, ain't it?
Most good SQL Developers would be disappointed if that took more than a handfull of milli-seconds regardless of how many...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 8, 2005 at 8:35 pm
All good points, Rudy... I'm used to good DBA's that take proper care of those things, so I tend to forget about them. My big problem has been that most...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 8, 2005 at 8:19 pm
Frank and Chris,
Because the 1st of January, 1900 was a Monday, this also works regardless of the setting of DateFirst.
DECLARE @Year CHAR(4)
DECLARE @ISOWeek VARCHAR(2)
SET...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 8, 2005 at 6:21 am
Nice article, Chris... excellent links, as well.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 8, 2005 at 5:08 am
Thanks Chris,
I'll take a look.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 8, 2005 at 4:54 am
Please tell me what version of Oracle has a FROM clause for UPDATEs? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2005 at 4:19 pm
If running from a scheduled batch job in a CMD window, convert the script to a stored proc, call it from OSQL, and use (> ) or the (-o) option...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2005 at 4:14 pm
Viewing 15 posts - 58,696 through 58,710 (of 59,067 total)