Viewing 15 posts - 47,341 through 47,355 (of 59,099 total)
Jeff Moden (11/10/2008)
That sounds more like problems with a table variable. Why aren't you using a temp table, instead?
Heh... sorry... I forgot... you're happy with the code you have....
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 9:25 pm
Continued at the following... on the 2k forum...
http://www.sqlservercentral.com/Forums/Topic599997-169-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 9:08 pm
You've got me... I use OPENROWSET for that type of stuff. Or, better yet, I'll have Excel write an importable CSV when they close the spreadsheet.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 8:55 pm
ajaykini (11/10/2008)
I have developed a web based software for a Multi level Marketing Company where one member joins and then gets 2 members below him - one on the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 8:52 pm
Business rules in triggers? I think that more than 95% of all business rules can either be resolved by the proper use of constraints and foreign keys on the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 8:31 pm
Shoot... 80MB for TempDB??? I boot the servers at work with 9GB... I doubt that I would boot any server with less than a gig for TempDB. And,...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 8:17 pm
I actually think a loop of some sort would probably be faster for this (GAK! I can't believe I just said that! :hehe:)... except for a couple of minor...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 8:06 pm
Heh... if you really want to throw a ball of wax at them before you decide to find a place with reasonable requirements, tell them the column should be named...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 6:06 pm
Heh... remove the ANSI joins and add old fashioned FROM's separated by comma's with no WHERE clause to cause a join. Then, add a distinct or a group by...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 5:57 pm
Remove the parenthesis from the parameter list... it's not a function...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 5:52 pm
I've restructured the WHERE clause without changing any of the code... I think the problem sticks out like a sore thumb...
WHERE (ET.iSiteId = @locSITEID)
...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 5:44 pm
SELECT SYSDATE FROM DUAL;
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 5:25 pm
eric (11/10/2008)
1, 'P1', 1, 2, 3, 4, 0
2, 'P1', 10,...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 4:54 pm
chandrika5 (11/10/2008)
That is a good suggestion. I converted the inner select/processing to a function and am calling this function in my select statement: no cursor required
As Lynn stated, you've probably...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 4:47 pm
Something else you might want to consider... the best hardware in the world won't solve performance problems if the code isn't quite up to it. I'd probably start by...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2008 at 4:28 pm
Viewing 15 posts - 47,341 through 47,355 (of 59,099 total)