Showing posts with label runs. Show all posts
Showing posts with label runs. Show all posts

Wednesday, March 28, 2012

Profiler

I really have never used the SQL Profiler, but I'm trying. I have a stored
procedure which runs just fine in query analyzer returning a few rows.
When I run it from a C# application, it returns "0" in the @.ERETURN_VALUE"
but no rows of data are returned.
I brought up Profiler and I am not really able to make heads or tails out
of this. What values should I select in profiler to see if any rows are
returned to the application?
Thanks in advance for your assistance...In your database exeute
select db_id() and take a note of the result
In the profiler on the filters tab go to the databaseID
equals entry and type in the value you extracted.
In events get rid of security audit and sessions.
Now when you run the profiler you will just trace
interactions with your database - usually that's enough to
find entries.
Run the app and you should see the SP call.
Copy this from the result window and run it in query
analyser (in a transaction if it does updates) and you
should see the problem.
>--Original Message--
>I really have never used the SQL Profiler, but I'm
trying. I have a stored
>procedure which runs just fine in query analyzer
returning a few rows.
>When I run it from a C# application, it returns "0" in
the @.ERETURN_VALUE"
>but no rows of data are returned.
>I brought up Profiler and I am not really able to make
heads or tails out
>of this. What values should I select in profiler to see
if any rows are
>returned to the application?
>
>Thanks in advance for your assistance...
>.
>

Production experience to share

I wanted to post this in case anyone else runs into it - save you loads of
time.
Yesterday we deployed our latest release of reports - someone forgot to move
the pin on the report in source control and yet the updated stored proc for
the report went out. Net result was the updated stored proc was out there
but the report wasn't. The new stored proc was requesting a new parameter
the report couldn't supply. Normally on our dev box we get the error message
back from reporting services rather quickly (~3 seconds). On our test box it
was taking 3 minutes and production was just hanging.
We are using C# to proxy all report requests (so nobody can hit the box
directly) and the error codes being returned to C# were basically saying that
reporting services was abruptly cutting the connection. We received Denial
of Service Attach messages, Tls errors, SSL/Tls trust errors and timeout
errors. Nothing returned about missing parameters - the exception object
doesn't receive detailed info as to why the connection was killed - only that
it was killed. In order to get the details we will have to modify the code
to go into the HTML returned by the WebRequest object.
I don't know why the report was hanging for as long as it was- I went into
the IIS logs to see what was being requested (fortunately we have to use URL
requests in our case) and when picking through the requests I noticed that it
wasn't passing in a required parameter. (The report didn't request it, so it
didn't pass it). When I recreated the request through report manager I
noticed that it wasn't using all of the parameters expected.
In our attempts we upped the MaxReqPerUser property in RSReportServer.config
file from default (20) to 140 as a guess - it helped for about 5 minutes,
then everybody crashed again.
Microsoft - hopefully the new RS release will interrogate the stored proc at
runtime and return results quicker? Hopefully error integration will be
better with C# next year? I doubt it b/c there may not be a good way to pass
errors to the exception object.
I am sharing this b/c I was on the phone with MS premier support ($$)
yesterday for 7 hours and they offered no creative ideas or really anything
of signifigance. Please add this to your knowledge base so the next guy
might avoid 12 hours of headache.
Any comments are welcomed!
John Hennesey
JohnHennesey82:hotmail.comThanks for sharing...I'll have to remember this one...
"JohnHennesey" <JohnHennesey@.discussions.microsoft.com> wrote in message
news:C285281B-4230-4114-8B3A-E303CB2FADD9@.microsoft.com...
>I wanted to post this in case anyone else runs into it - save you loads of
> time.
> Yesterday we deployed our latest release of reports - someone forgot to
> move
> the pin on the report in source control and yet the updated stored proc
> for
> the report went out. Net result was the updated stored proc was out there
> but the report wasn't. The new stored proc was requesting a new
> parameter
> the report couldn't supply. Normally on our dev box we get the error
> message
> back from reporting services rather quickly (~3 seconds). On our test box
> it
> was taking 3 minutes and production was just hanging.
> We are using C# to proxy all report requests (so nobody can hit the box
> directly) and the error codes being returned to C# were basically saying
> that
> reporting services was abruptly cutting the connection. We received
> Denial
> of Service Attach messages, Tls errors, SSL/Tls trust errors and timeout
> errors. Nothing returned about missing parameters - the exception object
> doesn't receive detailed info as to why the connection was killed - only
> that
> it was killed. In order to get the details we will have to modify the
> code
> to go into the HTML returned by the WebRequest object.
> I don't know why the report was hanging for as long as it was- I went into
> the IIS logs to see what was being requested (fortunately we have to use
> URL
> requests in our case) and when picking through the requests I noticed that
> it
> wasn't passing in a required parameter. (The report didn't request it, so
> it
> didn't pass it). When I recreated the request through report manager I
> noticed that it wasn't using all of the parameters expected.
> In our attempts we upped the MaxReqPerUser property in
> RSReportServer.config
> file from default (20) to 140 as a guess - it helped for about 5 minutes,
> then everybody crashed again.
> Microsoft - hopefully the new RS release will interrogate the stored proc
> at
> runtime and return results quicker? Hopefully error integration will be
> better with C# next year? I doubt it b/c there may not be a good way to
> pass
> errors to the exception object.
> I am sharing this b/c I was on the phone with MS premier support ($$)
> yesterday for 7 hours and they offered no creative ideas or really
> anything
> of signifigance. Please add this to your knowledge base so the next guy
> might avoid 12 hours of headache.
> Any comments are welcomed!
> John Hennesey
> JohnHennesey82:hotmail.com

Monday, March 26, 2012

Product level is insufficient error

Configuration: Windows XP Pro with SQL 2005 Workgroup Sp2

Hi, we have a package that runs fine in BI Studio but fails with the following error when executing it using DTExec.

Code: 0xC00470FE
Source: Data Flow Task DTS.Pipeline
Description: SSIS Error Code DTS_E_PRODUCTLEVELTOLOW. The product level is insufficient for component "Derived Column" (10660).

The package imports a CSV into a table mapping some columns. The MSDN article at http://msdn2.microsoft.com/en-us/library/ms143761.aspx describes features supported by different versions.

The article says OLE DB source/destination adapters are supported in WG edition but a couple of lines later seems to imply that all source/destination adapters are not supported in WG.

Could you clarify whether stuff like import of a csv into a table with some column mappings should work in WG edition? Also if we have a legacy SQL 2K package doing the same thing, will that work in WG edition? Thx.

Features/Integration Services Enhancements EE (32-bit) DE (32-bit) EE (64-bit) DE (64-bit) SE (32-bit) WG (32-bit) SSE (32-bit) SSEA (32-bit) SE (64-bit)

SQL Server Import and Export Wizard and supporting connections, source and destination adapters, and tasks

Yes

Yes

Yes

No

Yes

Execute SQL Task

Yes

Yes

Yes

No

Yes

OLE DB Source and Destination Adapters

Yes

Yes

Yes

No

Yes

SSIS command prompt tools

Yes

Yes

Yes

No

Yes

SSIS Package Designer

Yes

Yes

Yes

No

Yes

Legacy support for DTS packages

Yes

Yes

Yes

Yes

Yes

SSIS Service

Yes

Yes

No

No

Yes

All other source and destination adapters, tasks, and transformations, except for those listed below

Yes

Yes

No

No

Yes

You might want to be sure that you have actually installed the full SSIS client.|||

As Phil wrote, most likely you've only Workstation components installed and need to install full SSIS.

See Books Online and my blog for details:

http://msdn2.microsoft.com/en-US/library/aa337371.aspx

http://blogs.msdn.com/michen/archive/2006/11/11/ssis-product-level-is-insufficient.aspx

Produciton SQL CPU running around 50%

Our production SQL Server's CPU runs continuously at about
50%. Below is a copy of the running Process threads, taken
from SQL Spotlight. Can anyone help identify the
bottleneck and give recommendations for improvement
(besides improving queries)? Your help is greatly
appreciated!
InstanceThread ID% CPU% User% Kernel
Elapsed timeSwitches/secThread State
Thread Wait Reason
5268104.650106.3219d 10hrs207
921.65WaitingWaiting for a user request
0052.92052.92147417d 19hrs
807.51Running-
1050.18050.18147417d 19hrs
471.7Running-
3048.15048.15147417d 19hrs
495.51Running-
627240.76042.9119d 10hrs0
WaitingWaiting for a user request
2036.47036.47147417d 19hrs
710.07Running-
15102683594.66405.723188.949d
20hrs215661.8WaitingWaiting for a user
request
53441.910.361.5519d 10hrs1
134.55WaitingWaiting for a user request
12521906.93335.881571.0519d
10hrs229163.43WaitingWaiting for an LPC
Receive notice
42041830.41266.391564.0119d
10hrs133979.34WaitingWaiting for an LPC
Receive notice
84881810.26278.071532.1919d
10hrs0WaitingWaiting for an LPC Receive
notice
1141961683.68288.321395.3617d
17hrs197806.72WaitingWaiting for an LPC
Receive notice
1214081612.76281.77133117d
17hrs163851.13WaitingWaiting for an LPC
Receive notice
1342641596.43286.411310.0217d
17hrs135660.06WaitingWaiting for an LPC
Receive notice
0115840.790.7901d 6hrs
20.82WaitingWaiting for a user request
42760.3600.3619d 10hrs
58.45WaitingWaiting for a user request
32280.1200.1219d 10hrs9
WaitingWaiting for an LPC Receive notice
1027560.1200.1219d 8hrs
2.67WaitingWaiting for a user request
However, low CPU usage can be because the machine is waiting for I/O requests a lot. Tuning the
queries, by for instance adding indexes so less I/O is used can be a real benefit in these cases.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"James" <anonymous@.discussions.microsoft.com> wrote in message
news:6e2901c48392$136f9480$a401280a@.phx.gbl...[vbcol=seagreen]
> Come and check ours. It is running at 90% most of the time.
> CPU usage depends on the transactions occuring in the
> Server (Unless there are other applications running on the
> server). I wouldn't be too concern about it at 50%. If you
> are, use the SQL Profiler to find out what processes using
> the most CPU usage(the number on Profiler is in
> miliseconds).
>
> about
> taken

Produciton SQL CPU running around 50%

Our production SQL Server's CPU runs continuously at about
50%. Below is a copy of the running Process threads, taken
from SQL Spotlight. Can anyone help identify the
bottleneck and give recommendations for improvement
(besides improving queries)' Your help is greatly
appreciated!
Instance Thread ID % CPU % User % Kernel
Elapsed time Switches/sec Thread State
Thread Wait Reason
5 268 104.65 0 106.32 19d 10hrs 207
921.65 Waiting Waiting for a user request
0 0 52.92 0 52.92 147417d 19hrs
807.51 Running -
1 0 50.18 0 50.18 147417d 19hrs
471.7 Running -
3 0 48.15 0 48.15 147417d 19hrs
495.51 Running -
6 272 40.76 0 42.91 19d 10hrs 0
Waiting Waiting for a user request
2 0 36.47 0 36.47 147417d 19hrs
710.07 Running -
15 10268 3 594.66 405.72 3 188.94 9d
20hrs 215 661.8 Waiting Waiting for a user
request
5 344 1.91 0.36 1.55 19d 10hrs 1
134.55 Waiting Waiting for a user request
1 252 1 906.93 335.88 1 571.05 19d
10hrs 229 163.43 Waiting Waiting for an LPC
Receive notice
4 204 1 830.41 266.39 1 564.01 19d
10hrs 133 979.34 Waiting Waiting for an LPC
Receive notice
8 488 1 810.26 278.07 1 532.19 19d
10hrs 0 Waiting Waiting for an LPC Receive
notice
11 4196 1 683.68 288.32 1 395.36 17d
17hrs 197 806.72 Waiting Waiting for an LPC
Receive notice
12 1408 1 612.76 281.77 1 331 17d
17hrs 163 851.13 Waiting Waiting for an LPC
Receive notice
13 4264 1 596.43 286.41 1 310.02 17d
17hrs 135 660.06 Waiting Waiting for an LPC
Receive notice
0 11584 0.79 0.79 0 1d 6hrs
20.82 Waiting Waiting for a user request
4 276 0.36 0 0.36 19d 10hrs
58.45 Waiting Waiting for a user request
3 228 0.12 0 0.12 19d 10hrs 9
Waiting Waiting for an LPC Receive notice
10 2756 0.12 0 0.12 19d 8hrs
2.67 Waiting Waiting for a user requestHowever, low CPU usage can be because the machine is waiting for I/O request
s a lot. Tuning the
queries, by for instance adding indexes so less I/O is used can be a real be
nefit in these cases.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"James" <anonymous@.discussions.microsoft.com> wrote in message
news:6e2901c48392$136f9480$a401280a@.phx.gbl...[vbcol=seagreen]
> Come and check ours. It is running at 90% most of the time.
> CPU usage depends on the transactions occuring in the
> Server (Unless there are other applications running on the
> server). I wouldn't be too concern about it at 50%. If you
> are, use the SQL Profiler to find out what processes using
> the most CPU usage(the number on Profiler is in
> miliseconds).
>
>
> about
> taken

Produciton SQL CPU running around 50%

Our production SQL Server's CPU runs continuously at about
50%. Below is a copy of the running Process threads, taken
from SQL Spotlight. Can anyone help identify the
bottleneck and give recommendations for improvement
(besides improving queries)' Your help is greatly
appreciated!
Instance Thread ID % CPU % User % Kernel
Elapsed time Switches/sec Thread State
Thread Wait Reason
5 268 104.65 0 106.32 19d 10hrs 207
921.65 Waiting Waiting for a user request
0 0 52.92 0 52.92 147417d 19hrs
807.51 Running -
1 0 50.18 0 50.18 147417d 19hrs
471.7 Running -
3 0 48.15 0 48.15 147417d 19hrs
495.51 Running -
6 272 40.76 0 42.91 19d 10hrs 0
Waiting Waiting for a user request
2 0 36.47 0 36.47 147417d 19hrs
710.07 Running -
15 10268 3 594.66 405.72 3 188.94 9d
20hrs 215 661.8 Waiting Waiting for a user
request
5 344 1.91 0.36 1.55 19d 10hrs 1
134.55 Waiting Waiting for a user request
1 252 1 906.93 335.88 1 571.05 19d
10hrs 229 163.43 Waiting Waiting for an LPC
Receive notice
4 204 1 830.41 266.39 1 564.01 19d
10hrs 133 979.34 Waiting Waiting for an LPC
Receive notice
8 488 1 810.26 278.07 1 532.19 19d
10hrs 0 Waiting Waiting for an LPC Receive
notice
11 4196 1 683.68 288.32 1 395.36 17d
17hrs 197 806.72 Waiting Waiting for an LPC
Receive notice
12 1408 1 612.76 281.77 1 331 17d
17hrs 163 851.13 Waiting Waiting for an LPC
Receive notice
13 4264 1 596.43 286.41 1 310.02 17d
17hrs 135 660.06 Waiting Waiting for an LPC
Receive notice
0 11584 0.79 0.79 0 1d 6hrs
20.82 Waiting Waiting for a user request
4 276 0.36 0 0.36 19d 10hrs
58.45 Waiting Waiting for a user request
3 228 0.12 0 0.12 19d 10hrs 9
Waiting Waiting for an LPC Receive notice
10 2756 0.12 0 0.12 19d 8hrs
2.67 Waiting Waiting for a user requestCome and check ours. It is running at 90% most of the time.
CPU usage depends on the transactions occuring in the
Server (Unless there are other applications running on the
server). I wouldn't be too concern about it at 50%. If you
are, use the SQL Profiler to find out what processes using
the most CPU usage(the number on Profiler is in
miliseconds).
>--Original Message--
>Our production SQL Server's CPU runs continuously at
about
>50%. Below is a copy of the running Process threads,
taken
>from SQL Spotlight. Can anyone help identify the
>bottleneck and give recommendations for improvement
>(besides improving queries)' Your help is greatly
>appreciated!
>Instance Thread ID % CPU % User % Kernel
> Elapsed time Switches/sec Thread State
> Thread Wait Reason
>5 268 104.65 0 106.32 19d 10hrs 207
> 921.65 Waiting Waiting for a user request
>0 0 52.92 0 52.92 147417d 19hrs
> 807.51 Running -
>1 0 50.18 0 50.18 147417d 19hrs
> 471.7 Running -
>3 0 48.15 0 48.15 147417d 19hrs
> 495.51 Running -
>6 272 40.76 0 42.91 19d 10hrs 0
> Waiting Waiting for a user request
>2 0 36.47 0 36.47 147417d 19hrs
> 710.07 Running -
>15 10268 3 594.66 405.72 3 188.94 9d
> 20hrs 215 661.8 Waiting Waiting for a user
>request
>5 344 1.91 0.36 1.55 19d 10hrs 1
> 134.55 Waiting Waiting for a user request
>1 252 1 906.93 335.88 1 571.05 19d
> 10hrs 229 163.43 Waiting Waiting for an LPC
>Receive notice
>4 204 1 830.41 266.39 1 564.01 19d
> 10hrs 133 979.34 Waiting Waiting for an LPC
>Receive notice
>8 488 1 810.26 278.07 1 532.19 19d
> 10hrs 0 Waiting Waiting for an LPC Receive
>notice
>11 4196 1 683.68 288.32 1 395.36 17d
> 17hrs 197 806.72 Waiting Waiting for an LPC
>Receive notice
>12 1408 1 612.76 281.77 1 331 17d
> 17hrs 163 851.13 Waiting Waiting for an LPC
>Receive notice
>13 4264 1 596.43 286.41 1 310.02 17d
> 17hrs 135 660.06 Waiting Waiting for an LPC
>Receive notice
>0 11584 0.79 0.79 0 1d 6hrs
> 20.82 Waiting Waiting for a user request
>4 276 0.36 0 0.36 19d 10hrs
> 58.45 Waiting Waiting for a user request
>3 228 0.12 0 0.12 19d 10hrs 9
> Waiting Waiting for an LPC Receive notice
>10 2756 0.12 0 0.12 19d 8hrs
> 2.67 Waiting Waiting for a user request
>
>.
>|||However, low CPU usage can be because the machine is waiting for I/O requests a lot. Tuning the
queries, by for instance adding indexes so less I/O is used can be a real benefit in these cases.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"James" <anonymous@.discussions.microsoft.com> wrote in message
news:6e2901c48392$136f9480$a401280a@.phx.gbl...
> Come and check ours. It is running at 90% most of the time.
> CPU usage depends on the transactions occuring in the
> Server (Unless there are other applications running on the
> server). I wouldn't be too concern about it at 50%. If you
> are, use the SQL Profiler to find out what processes using
> the most CPU usage(the number on Profiler is in
> miliseconds).
>
> >--Original Message--
> >Our production SQL Server's CPU runs continuously at
> about
> >50%. Below is a copy of the running Process threads,
> taken
> >from SQL Spotlight. Can anyone help identify the
> >bottleneck and give recommendations for improvement
> >(besides improving queries)' Your help is greatly
> >appreciated!
> >
> >Instance Thread ID % CPU % User % Kernel
> > Elapsed time Switches/sec Thread State
> > Thread Wait Reason
> >5 268 104.65 0 106.32 19d 10hrs 207
> > 921.65 Waiting Waiting for a user request
> >
> >0 0 52.92 0 52.92 147417d 19hrs
> > 807.51 Running -
> >1 0 50.18 0 50.18 147417d 19hrs
> > 471.7 Running -
> >3 0 48.15 0 48.15 147417d 19hrs
> > 495.51 Running -
> >6 272 40.76 0 42.91 19d 10hrs 0
> > Waiting Waiting for a user request
> >
> >2 0 36.47 0 36.47 147417d 19hrs
> > 710.07 Running -
> >15 10268 3 594.66 405.72 3 188.94 9d
> > 20hrs 215 661.8 Waiting Waiting for a user
> >request
> >5 344 1.91 0.36 1.55 19d 10hrs 1
> > 134.55 Waiting Waiting for a user request
> >
> >1 252 1 906.93 335.88 1 571.05 19d
> > 10hrs 229 163.43 Waiting Waiting for an LPC
> >Receive notice
> >4 204 1 830.41 266.39 1 564.01 19d
> > 10hrs 133 979.34 Waiting Waiting for an LPC
> >Receive notice
> >8 488 1 810.26 278.07 1 532.19 19d
> > 10hrs 0 Waiting Waiting for an LPC Receive
> >notice
> >11 4196 1 683.68 288.32 1 395.36 17d
> > 17hrs 197 806.72 Waiting Waiting for an LPC
> >Receive notice
> >12 1408 1 612.76 281.77 1 331 17d
> > 17hrs 163 851.13 Waiting Waiting for an LPC
> >Receive notice
> >13 4264 1 596.43 286.41 1 310.02 17d
> > 17hrs 135 660.06 Waiting Waiting for an LPC
> >Receive notice
> >0 11584 0.79 0.79 0 1d 6hrs
> > 20.82 Waiting Waiting for a user request
> >
> >4 276 0.36 0 0.36 19d 10hrs
> > 58.45 Waiting Waiting for a user request
> >
> >3 228 0.12 0 0.12 19d 10hrs 9
> > Waiting Waiting for an LPC Receive notice
> >
> >10 2756 0.12 0 0.12 19d 8hrs
> > 2.67 Waiting Waiting for a user request
> >
> >
> >.
> >

Monday, February 20, 2012

procedure runs with an error??

This is my procedure and the error is incorrect syntax near '01'

DECLARE @.returnDay int

--Looking at current date,
SELECT @.returnDay = DatePart(day,GetDate())
--If is the 7th of the current moth then
If @.returnDay = 24

EXEC master.dbo.xp_sendmail
@.query = 'SELECT a.HospitalName,a.HospitalCode, c.ProductName,b.UnitsDiscarded,d.FateOfProducts,b. DateEntered,
b.DateCompleted,b.CompiledBy FROM test.dbo.Units b inner join Hospitals a ON (a.HospitalID = b.HospitalID)
inner join Products c ON (b.ProductID = c.ProductID)
inner join FateOfProducts d ON (d.FateID = b.FateID)
where b. DateEntered = DateAdd(month, -1, Convert(CHAR(8), GetDate(), 121) + '01') order by a.HospitalID',
@.recipients=test@.hotmail.com', @.message='Submitting Results for the previous month',
@.subject=' results for previous month', @.attach_results = 'true', @.separator = '/s'

SELECT @.@.ERROR As ErrorNumber

What am I missing here now, I am quite new to stored procedures

REgardsEXEC master.dbo.xp_sendmail
@.query = "SELECT a.HospitalName,a.HospitalCode, c.ProductName,b.UnitsDiscarded,d.FateOfProducts,b. DateEntered,
b.DateCompleted,b.CompiledBy FROM test.dbo.Units b inner join Hospitals a ON (a.HospitalID = b.HospitalID)
inner join Products c ON (b.ProductID = c.ProductID)
inner join FateOfProducts d ON (d.FateID = b.FateID)
where b. DateEntered = DateAdd(month, -1, Convert(CHAR(8), GetDate(), 121) + '01') order by a.HospitalID",
@.recipients=test@.hotmail.com', @.message='Submitting Results for the previous month',
@.subject=' results for previous month', @.attach_results = 'true', @.separator = '/s'|||Thank you for your help.
Now I have this error message

The identifier that starts with 'SELECT a.HospitalName,c.ProductName,b.UnitsDiscarded,d.Fa teOfProducts,b.DateEntered,
b.DateCompleted,b.CompiledBy
FROM Test.database' is too long. Maximum length is 128.

I have seen this error but not a solution for it...
Could you help me with that?|||it seems that the allowed lenght of the @.query is 128 only so it is giving an error.|||Yeah I got that too,but I need all the data from the query so how I am suppose to go around it, any suggestions...|||Yeah I got that too,but I need all the data from the query so how I am suppose to go around it, any suggestions...

how about using a staging table (some temp table) to get the results and while sending the mail just select the records from this staging table?|||I hope I am not annoying everybody,but how do I use the temp table,do I create a replica of a table that has all the data or...I see what you mean expect I don't quite know what is my next step...

Any help appreciated|||set quoted_identifier off
EXEC master.dbo.xp_sendmail
@.query = "SELECT a.HospitalName,a.HospitalCode, c.ProductName,b.UnitsDiscarded,d.FateOfProducts,b. DateEntered,
b.DateCompleted,b.CompiledBy FROM test.dbo.Units b inner join Hospitals a ON (a.HospitalID = b.HospitalID)
inner join Products c ON (b.ProductID = c.ProductID)
inner join FateOfProducts d ON (d.FateID = b.FateID)
where b. DateEntered = DateAdd(month, -1, Convert(CHAR(8), GetDate(), 121) + '01') order by a.HospitalID",
@.recipients='test@.hotmail.com', @.message='Submitting Results for the previous month',
@.subject=' results for previous month', @.attach_results = 'true', @.separator = '/s'|||I hope I am not annoying everybody,but how do I use the temp table,do I create a replica of a table that has all the data or...I see what you mean expect I don't quite know what is my next step...

Any help appreciated
SELECT a.HospitalName,a.HospitalCode, c.ProductName,b.UnitsDiscarded,d.FateOfProducts,b. DateEntered,
b.DateCompleted,b.CompiledBy into #temp FROM master.dbo.units b inner join Hospitals a ON (a.HospitalID = b.HospitalID)
inner join Products c ON (b.ProductID = c.ProductID)
inner join FateOfProducts d ON (d.FateID = b.FateID)
where b. DateEntered = DateAdd(month, -1, Convert(CHAR(8), GetDate(), 121) + '01') order by a.HospitalID

EXEC master.dbo.xp_sendmail
@.query = "SELECT * from #temp",
@.recipients=test@.hotmail.com', @.message='Submitting Results for the previous month',
@.subject=' results for previous month', @.attach_results = 'true', @.separator = '/s'|||set quoted_identifier off
EXEC master.dbo.xp_sendmail
@.query = "SELECT a.HospitalName,a.HospitalCode, c.ProductName,b.UnitsDiscarded,d.FateOfProducts,b. DateEntered,
b.DateCompleted,b.CompiledBy FROM test.dbo.Units b inner join Hospitals a ON (a.HospitalID = b.HospitalID)
inner join Products c ON (b.ProductID = c.ProductID)
inner join FateOfProducts d ON (d.FateID = b.FateID)
where b. DateEntered = DateAdd(month, -1, Convert(CHAR(8), GetDate(), 121) + '01') order by a.HospitalID",
@.recipients='test@.hotmail.com', @.message='Submitting Results for the previous month',
@.subject=' results for previous month', @.attach_results = 'true', @.separator = '/s'

:eek:
smart|||Thank you guys heaps...|||By default in SQL Server 2000 ... the entries inside "" (double quotes) are taken as identifiers ... you need to turn them off while using them as a way to avoid this happening.

alternatively you can use the single quote two times to use them within a string

eg .


set quoted_identifier off
EXEC master.dbo.xp_sendmail
@.query = 'SELECT a.HospitalName,a.HospitalCode, c.ProductName,b.UnitsDiscarded,d.FateOfProducts,b. DateEntered,
b.DateCompleted,b.CompiledBy FROM test.dbo.Units b inner join Hospitals a ON (a.HospitalID = b.HospitalID)
inner join Products c ON (b.ProductID = c.ProductID)
inner join FateOfProducts d ON (d.FateID = b.FateID)
where b. DateEntered = DateAdd(month, -1, Convert(CHAR(8), GetDate(), 121) + ''01'') order by a.HospitalID',
@.recipients='test@.hotmail.com', @.message='Submitting Results for the previous month',
@.subject=' results for previous month', @.attach_results = 'true', @.separator = '/s'


I hope I have been able to explain it clearly ...|||Excellent, many thanks