Viewing 15 posts - 50,596 through 50,610 (of 59,099 total)
Sergiy (5/12/2008)
I would suggest:
1) create simple ReportTable
(
SeqNo smallint NOT NULL PRIMARY KEY,
ReportString varchar(8000) NULL
)
2) Populate this table with lines to be reported, lines...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 11:35 pm
If you really want it in a single query, create a function using the same technique. Your turn... why does it have to be in a single query?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 11:25 pm
Last half of the following article tells you how to do a "split". Just replace the ? with a \ in the URL, remove the first 7 characters, and...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 11:23 pm
robertcaustin (5/12/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 11:19 pm
I believe I'd start wtih the Index Tuning Advisor and then tweek from there.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 11:16 pm
First, the function you have uses a cursor/while loop and it's going to be relatively slow. See the following for a couple of tips how to do it another...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 11:07 pm
Please read the following for the solution to the Running Total (Balance) problem including Grouped Running Totals...
http://www.sqlservercentral.com/articles/Advanced+Querying/61716/
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 10:37 pm
Why did you specify one table per service type instead of 1 table to hold all service types? And if employees suffer no cost, why did you make a...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 10:23 pm
Yes, a cursor can have a join to multiple tables in it... but using a cursor is usually a mistake.
Store procs don't have to return anything... functions do.
These are sweeping...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 10:17 pm
... an unless you've made the server case sensitive, there's no need for UPPER anywhere in the query.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 10:09 pm
Google for ...
sp_MSForEachDB
sp_MSForEachTable
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 10:04 pm
Heh... two way street here... would you mind posting your solution, please? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 10:01 pm
I'll second that... just remember that they teach ANSI SQL... nothing really advanced.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 10:00 pm
How many words are in HTMLBody and can I see an example of 10 rows, please?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 9:54 pm
I'd convert all of the WHERE IN's to proper joins and see if the proper indexes are in place. I'd also use a SELECT list instead of * to...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2008 at 9:30 pm
Viewing 15 posts - 50,596 through 50,610 (of 59,099 total)