Increase the Rendering Timing of Reports

Hi,

We are using SQL Server 2005 Reporting Services for creating Reports. But report execution is taking bit time to give results.

Is there any way around to increase the rendering timing ?

Thx

First step would be to find where the delay is. There is a table called ExecutionLog in the reportserver database catalog. you can query this table and look at columns - TimeDataRetrival, Time processing, time rendering for this report to find out where the delay is. If the delay is in TimeDataRetrival, it means that your SQL query performance is the one to be blamed. You can optimize the query which is used in the report and get over it. NOTE: Always open the ExecutionLog table with no lock hint.

Incorrect values in RestoreHistory table

We have a SQL Server which is setting the wrong recovery bit in the table
msdb..restorehistory
i.e.
when databases restored WITH RECOVERY the recovery field has a value of 0
when databases restored WITH NORECOVERY the recovery field has a value of 1
I cannot find out why this is happening. Please assist
ThanksThe BOL is incorrect, 0 means Recovery, and 1 NORECOVERY.
>--Original Message--
>We have a SQL Server which is setting the wrong recovery
bit in the table
>msdb..restorehistory
>i.e.
>when databases restored WITH RECOVERY the recovery field
has a value of 0
>when databases restored WITH NORECOVERY the recovery
field has a value of 1
>I cannot find out why this is happening. Please assist
>Thanks
>
>.
>|||Thanks,
I thought I had verified this with the other servers, but
after double checking with the scritped test below, I
notice that you are correct
Is there any way to send feedbacks to Microsoft about
this, as I frequently find such things
/************Test RestoreHistory Entries******************/
create database test
backup database test to disk = '%temp%\t'
restore database test from disk = 't'
restore database test from disk = 't' with norecovery
restore database test from disk = 't' with recovery
select * from msdb..restorehistory where
destination_database_name = 'test' order by restore_date
drop database test
declare @.bdir varchar(255)
exec
master..xp_regread 'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft
\MSSQLServer\MSSQLServer',
'BackupDirectory', @.bdir OUTPUT
set @.bdir = 'del "'+@.bdir+'\t"'
exec master..xp_cmdshell @.bdir
/*********************************************************/
>--Original Message--
>The BOL is incorrect, 0 means Recovery, and 1 NORECOVERY.
>>--Original Message--
>>We have a SQL Server which is setting the wrong recovery
>bit in the table
>>msdb..restorehistory
>>i.e.
>>when databases restored WITH RECOVERY the recovery field
>has a value of 0
>>when databases restored WITH NORECOVERY the recovery
>field has a value of 1
>>I cannot find out why this is happening. Please assist
>>Thanks
>>
>>.
>.
>|||Mike,
> Is there any way to send feedbacks to Microsoft about
> this, as I frequently find such things
Yes, there's a feedback option in Books Online. Top left of the right pane.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Mike" <anonymous@.discussions.microsoft.com> wrote in message
news:0ea801c3b2d4$cbe095d0$a001280a@.phx.gbl...
> Thanks,
> I thought I had verified this with the other servers, but
> after double checking with the scritped test below, I
> notice that you are correct
> Is there any way to send feedbacks to Microsoft about
> this, as I frequently find such things
> /************Test RestoreHistory Entries******************/
> create database test
> backup database test to disk = '%temp%\t'
> restore database test from disk = 't'
> restore database test from disk = 't' with norecovery
> restore database test from disk = 't' with recovery
> select * from msdb..restorehistory where
> destination_database_name = 'test' order by restore_date
> drop database test
> declare @.bdir varchar(255)
> exec
> master..xp_regread 'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft
> \MSSQLServer\MSSQLServer',
> 'BackupDirectory', @.bdir OUTPUT
> set @.bdir = 'del "'+@.bdir+'\t"'
> exec master..xp_cmdshell @.bdir
> /*********************************************************/
>
> >--Original Message--
> >The BOL is incorrect, 0 means Recovery, and 1 NORECOVERY.
> >>--Original Message--
> >>We have a SQL Server which is setting the wrong recovery
> >bit in the table
> >>msdb..restorehistory
> >>
> >>i.e.
> >>when databases restored WITH RECOVERY the recovery field
> >has a value of 0
> >>when databases restored WITH NORECOVERY the recovery
> >field has a value of 1
> >>
> >>I cannot find out why this is happening. Please assist
> >>
> >>Thanks
> >>
> >>
> >>.
> >>
> >.
> >sql

Incorrect value returned from Stored Procedure

I have an asp.net 1.1 website that uses sql server 2000 and vb.

I have a bit of a dilema, when I run a stored procedure in a webpage it returns the wrong value, but if I run it

in the query analyzer the correct value is returned.

 Dim orderHistory As nlb.OrdersDB = New nlb.OrdersDB ' Obtain Order ID from QueryString Dim OrderID As Integer = CInt(Request.Params("ID")) ' Get the customer ID too Dim myNewCustomerId As Integer = 0 myNewCustomerId = orderHistory.GetOrderCustomer(OrderID) Public Function GetOrderCustomer(ByVal orderID As Integer) As Integer ' Create Instance of Connection and Command Object Dim myConnection As SqlConnection = New SqlConnection(ConfigurationSettings.AppSettings("ConnectionString")) Dim myCommand As SqlCommand = New SqlCommand("nlbsp_OrdersCustomerID", myConnection) ' Mark the Command as a SPROC myCommand.CommandType = CommandType.StoredProcedure ' Add Parameters to SPROC Dim parameterOrderID As New SqlParameter("@.order_id", SqlDbType.Int, 4) parameterOrderID.Value = orderID myCommand.Parameters.Add(parameterOrderID) Dim parameterOrderCustID As New SqlParameter("@.customer_id", SqlDbType.Int, 4) parameterOrderCustID.Value = ParameterDirection.Output myCommand.Parameters.Add(parameterOrderCustID) 'Open the connection and execute the Command myConnection.Open() myCommand.ExecuteNonQuery() myConnection.Close() ' Return the customer_id (obtained as out paramter of SPROC) If parameterOrderCustID.Value <> 0 Then Return CInt(parameterOrderCustID.Value) Else Return 0 End If End Functionthe stored procdure isCREATE PROCEDURE [dbo].[nlbsp_OrdersCustomerID]( @.order_id int, @.customer_id int OUTPUT)AS/* Return the customer_id from the Orders. */SELECT @.customer_id = customer_id FROM nlb_Orders WHERE order_id = @.order_idGO

I know a particular order_id returns a value of 1. But when I run it in the webpage it always comes back as 2.

Any ideas would be appreciated

Thanks

Pete

Seems you made a small mistake:

parameterOrderCustID.Value = ParameterDirection.Output

It should be:

Dim CustomerID As Integer
parameterOrderCustID.Value = CustomerID
parameterOrderCustID.Direction=ParameterDirection.Output

Incorporating Data Mining Wizard into a program?

Is there any way to incorporate the SQL 2005 Mining Wizard into my program? Sure, I can create my own mining wizard using DMX, but that's quite a bit of work. Has anyone tried this? Is it possible? Any pointers?

-Young K

Unfortunately the Data Mining wizard is not a seperable component and is not intended or licensed for reuse in other programs.|||

Thanks. I thought as much. Also, thanks for the webcasts, Jamie. They are quite helpful.

-Young K.

|||You're welcome

Inconsistent/Missing Information on Bit Special Datatype

Hello all,
I did some research trying to find an answer but was unsuccesessful.

Here's my question, does the bit special datatype support a null value in SQL 2000/2003?

I found an article on SQL 7.0 dated Mar 2001 by Sergey Vartanyan that states:

"Bit datatype is usually used for true/false or yes/no types of data, because it holds either 1 or 0. All integer values other than 1 or 0 are always interpreted as 1. One bit column stores in 1 byte, but multiple bit types in a table can be collected into bytes. Bit columns cannot be NULL and cannot have indexes on them."

On the other hand, when I look out at Microsoft's MSDN site I find the following in regards to SQL 2000:

"Consists of either a 1 or a 0. Use the bit data type when representing TRUE or FALSE, or YES or NO."

There is also this reference to bit for Transact SQL:
"Transact-SQL Reference
bit
Integer data type 1, 0, or NULL."

My personal opinion is if you require a 'yes/no' field, you wouldn't want to allow NULLs.

My reason for asking is I'm migrating from Access to SQL and within the Access tables some of the fields are YES/NO datatype but have Null values in some of the records.

One last thing, I know I can set it to a default of 0 or 1, but since I didn't write the application, I don't want to second guess the programmer. If newer versions of SQL will support NULL on the bit datatype, then it makes things easier for me.

Thanks in advance for any and all help.
T. MullinsThat is a $64,000 dollar question.

BOL states:

"Microsoft SQL Server optimizes the storage used for bit columns. If there are 8 or fewer bit columns in a table, the columns are stored as 1 byte. If there are from 9 through 16 bit columns, they are stored as 2 bytes, and so on."

So it would appear that a bit value can take up as little as 1 bit of space. But bit values can clearly store NULLs:
--------
declare @.BitTest bit
Print @.BitTest

set @.BitTest = 0
select @.BitTest

set @.BitTest = null
select @.BitTest
---------
So how is it possible to store three possible states (1, 0, Null) in a single computer bit?

Obviously something else is going on behind the scenes, but I've never seen an explanation for it either.

blindman|||Originally posted by blindman
That is a $64,000 dollar question.

BOL states:

"Microsoft SQL Server optimizes the storage used for bit columns. If there are 8 or fewer bit columns in a table, the columns are stored as 1 byte. If there are from 9 through 16 bit columns, they are stored as 2 bytes, and so on."

So it would appear that a bit value can take up as little as 1 bit of space. But bit values can clearly store NULLs:
--------
declare @.BitTest bit
Print @.BitTest

set @.BitTest = 0
select @.BitTest

set @.BitTest = null
select @.BitTest
---------
So how is it possible to store three possible states (1, 0, Null) in a single computer bit?

Obviously something else is going on behind the scenes, but I've never seen an explanation for it either.

blindman

Hey Blindman,
Thanks for the input. I guess I'll fall back on providing a default value if no data is passed in.

Inconsistent sp_spaceused

Nope, didn't help a bit: still shows 0 records yet roughly 7MB of taken space.
"Tibor Karaszi" wrote:

> Check out DBCC UPDATEUSAGE and the ROWS_COUNT option.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Leon Shargorodsky" <LeonShargorodsky@.discussions.microsoft.com> wrote in message
> news:A1FBD362-9CB9-41F1-A57A-6662C4BFF5A8@.microsoft.com...
>
>
Leon Shargorodsky,
if you dropped a variable length column, you can reclaim the space using
"dbcc cleantable".
If it is a heap (table without clustered index), create a clustered index
and if you do not want to keep it then drop it.
If it is not a heap, use "dbcc dbreindex" or "alter index ... rebuild" if
you are using 2005.
AMB
"Leon Shargorodsky" wrote:
[vbcol=seagreen]
> Nope, didn't help a bit: still shows 0 records yet roughly 7MB of taken space.
> "Tibor Karaszi" wrote: