Viewing 15 posts - 53,311 through 53,325 (of 59,072 total)
Madhivanan (12/28/2007)
You need to use IS NULL or IS NOT NULL to check againt NULL
Actually, for the problem I posted, that's absolutely NOT true. Do you know why? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 12:29 am
jose (12/6/2007)
How can i apply this if I'm using sql server 2000? (because the problem of the variable @sql =varchar(8000), in sql server 2000 doesnt...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 12:24 am
shashi kant (12/7/2006)
Instand of using this thing u can use the Table variable while loop which help lot compare to Cursor...
Actually, that's an old wive's tale... a "Firehose" cursor is...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 12:13 am
These should help...
http://www.databasejournal.com/features/mssql/article.php/1462641
http://codebetter.com/blogs/raymond.lewallen/archive/2005/09/12/131869.aspx
http://www.novicksoftware.com/UDFofWeek/Vol2/T-SQL-UDF-Vol-2-Num-41-udf_Sys_RegReadStr.htm
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 12:06 am
Step 1... take the data provider out to dinner... feed the data provider a nice juicy pork chop... with a slingshot!
Seriously... my first step would be to get the data...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 11:51 pm
Except for one brief mention somewhere above, everyone is talking about the physical aspects of those things needed to maintain a large database and, of course, all the tricks you...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 11:41 pm
...and all I really need is a distinct list of what you currently have for RunStatuses...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 11:04 pm
Did you actually try the code I wrote? Like I said, it should be good for about 132 run statuses... number of features don't matter in this code...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 11:01 pm
Steve, if you come anywhere near Detroit, let me know... I gotta meet you some day and it's not likely I'll make it out to your farm!
And congrats on making...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:40 pm
PLEASE don't double post anymore... spreads resources too thin.
http://www.sqlservercentral.com/Forums/Topic436548-146-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:35 pm
PLEASE don't double post anymore... spreads resources too thin.
http://www.sqlservercentral.com/Forums/Topic436564-5-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:34 pm
Please don't double post... spreads resources too thin.
http://www.sqlservercentral.com/Forums/Topic436885-146-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:30 pm
Here's a slightly better rendition based on what you just posted...
Should be good for about 132 columns of RunStatuses not including Feature.
DROP TABLE Raw
GO
CREATE TABLE Raw (TestListID INT, Feature VARCHAR(256),...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:27 pm
...and, you're saying this didn't work?
CREATE TABLE Raw (TestListID INT, Feature VARCHAR(256), RunStatus VARCHAR(64),
...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:16 pm
Are you saying that you'd rather have the run status in columns instead of rows?
In other words, each row would be a Feature and each column would be a RunStatus...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 9:32 pm
Viewing 15 posts - 53,311 through 53,325 (of 59,072 total)