Viewing 15 posts - 53,326 through 53,340 (of 59,089 total)
Exactly what I did in my cross-tab code... nice, job, Koji...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 1:11 am
Ok... enough suspense... I'll tell you why... first a review of the dreadful mistake that a lot of developers make. A developer has to solve the problem of returning...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 12:49 am
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
Viewing 15 posts - 53,326 through 53,340 (of 59,089 total)