Showing posts with label creating. Show all posts
Showing posts with label creating. Show all posts

Friday, March 30, 2012

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.

Wednesday, March 28, 2012

Incorrect syntax near XML-While creating XML Schema

Hi,

Im trying to create a xml schema like


CREATE XML SCHEMA COLLECTION BooksSchemaCollection AS
N'<?xml version="1.0" encoding="UTF-16"?>
<xsd:schema elementFormDefault="unqualified"
attributeFormDefault="unqualified"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" >
<xsd:element name="book">
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="author" type="xsd:string"/>
<xsd:element name="publisher" type="xsd:string"/>
<xsd:element name="cost" type="xsd:integer"/>
<xsd:element name="comments" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>';

But when i execute , im getting a error like Incorrect syntax near 'XML' .any one know why its comming??

Thanks

Hi ,

I use SqlServer 2005 and above SQL statement works fine on my pc.

Make sure you have correct permission.

To create an XML SCHEMA COLLECTION requires at least one of the following sets of permissions:

CONTROL permission on the server
ALTER ANY DATABASE permission on the server
ALTER permission on the database
CONTROL permission in the database
ALTER ANY SCHEMA permission and CREATE XML SCHEMA COLLECTION permission in the database
ALTER or CONTROL permission on the relational schema and CREATE XML SCHEMA COLLECTION permission in the database
sql

Wednesday, March 21, 2012

incorrect settings: ANSI_NULLS., QUOTED_IDENTIFIER.

Getting an "incorrect settings: 'ANSI_NULLS., QUOTED_IDENTIFIER'."
error after creating a view.

We wanted a composite unique constraint that ignored nulls, so we set
up a view using the following script:

/* -- start -- */
BEGIN TRANSACTION
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
COMMIT

GO

CREATE VIEW vw_MyView
WITH SCHEMABINDING
AS
SELECT Col1, Col2 FROM dbo.MyTable WHERECol2 IS NOT NULL

GO
/* -- end -- */

and then added the constraint to the new view

/* -- start -- */
CREATE UNIQUE CLUSTERED INDEX AK_MyTable_Constraint1 ON
vw_MyView(Col1, Col2)

GO
/* -- end -- */

I thought we were doing fine, 'til we started running some DELETE
stored procedures and got the above error. The error also cited
ARITHABORT as an incorrect setting until we ran this script:

/* -- start -- */
USE master
DECLARE @.value int
SELECT @.value = value FROM syscurconfigs
WHERE config = 1534
SET @.value = @.value | 64

EXEC sp_configure 'user options', @.value
RECONFIGURE
/* -- end -- */

TIA to anyone kind enough to shed some light on this for me. Is there
something we should have done differently in creating the view and
index? If not, what's the procedure for working through these
settings errors?

I've read through some other threads on this subject, but didn't
really find what I was looking for. Thanks again for any help. Would
be appreciated.

-mattmatty2112@.hotmail.com (Matt Rink) wrote in message news:<1b11065c.0310262201.4f2ba70a@.posting.google.com>...
> Getting an "incorrect settings: 'ANSI_NULLS., QUOTED_IDENTIFIER'."
> error after creating a view.
> We wanted a composite unique constraint that ignored nulls, so we set
> up a view using the following script:
> /* -- start -- */
> BEGIN TRANSACTION
> SET QUOTED_IDENTIFIER ON
> SET ARITHABORT ON
> SET NUMERIC_ROUNDABORT OFF
> SET CONCAT_NULL_YIELDS_NULL ON
> SET ANSI_NULLS ON
> SET ANSI_PADDING ON
> SET ANSI_WARNINGS ON
> COMMIT
> GO
> CREATE VIEW vw_MyView
> WITH SCHEMABINDING
> AS
> SELECT Col1, Col2 FROM dbo.MyTable WHERECol2 IS NOT NULL
> GO
> /* -- end -- */
> and then added the constraint to the new view
> /* -- start -- */
> CREATE UNIQUE CLUSTERED INDEX AK_MyTable_Constraint1 ON
> vw_MyView(Col1, Col2)
> GO
> /* -- end -- */
> I thought we were doing fine, 'til we started running some DELETE
> stored procedures and got the above error. The error also cited
> ARITHABORT as an incorrect setting until we ran this script:
> /* -- start -- */
> USE master
> DECLARE @.value int
> SELECT @.value = value FROM syscurconfigs
> WHERE config = 1534
> SET @.value = @.value | 64
> EXEC sp_configure 'user options', @.value
> RECONFIGURE
> /* -- end -- */
> TIA to anyone kind enough to shed some light on this for me. Is there
> something we should have done differently in creating the view and
> index? If not, what's the procedure for working through these
> settings errors?
> I've read through some other threads on this subject, but didn't
> really find what I was looking for. Thanks again for any help. Would
> be appreciated.
> -matt

You need to have those SET options in force not only when you create
the view and indexes, but also when you query it. So your client
application has to use the same settings in its code - OLE DB/ODBC
does this automatically, with the exception of ARITHABORT. In BOL,
Microsoft recommend to set this on at the server level, as you've done
already.

If you still have errors when using the indexed view, it is most
likely that you have some stored procedures which have been created
with ANSI_NULLS and QUOTED_IDENTIFIER off, not on - those settings are
fixed when the procedure is created. You can recreate the procedures
with the correct SET options, and it should work fine, although of
course that change could affect other code, so you need to test it.

Simon|||Hi Matt

As Doug and Simon have said, stored procedures created with certain SET
options enabled will always run with those options, even if you SET them
differently in the batch that calls the procedure. The only two that are
stored this way are "ANSI_NULLS" and "QUOTED_IDENTIFIER". I call these
'sticky' options, because their values 'stick' to the stored procedure.
Since these are the two you are getting messages about, it seems likely that
your procedure was created with the wrong values for these options,.

You can verify whether these options are set with the procedure by using the
OBJECTPROPERTY FUNCTION:

SELECT OBJECTPROPERTY(object_id('proc name'), 'ExecIsAnsiNullsOn' )

SELECT OBJECTPROPERTY(object_id('proc name'), 'ExecIsQuotedIdentOn')

If the functions return 1, the property was set, if they return 0, it was
NOT set for the procedure, and you MUST recreate the procedure to use it
with an indexed view.

(If the function returns NULL, it means you typed something wrong. :-) )
--
HTH
------
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com

"Matt Rink" <matty2112@.hotmail.com> wrote in message
news:1b11065c.0310262201.4f2ba70a@.posting.google.c om...
> Getting an "incorrect settings: 'ANSI_NULLS., QUOTED_IDENTIFIER'."
> error after creating a view.
> We wanted a composite unique constraint that ignored nulls, so we set
> up a view using the following script:
> /* -- start -- */
> BEGIN TRANSACTION
> SET QUOTED_IDENTIFIER ON
> SET ARITHABORT ON
> SET NUMERIC_ROUNDABORT OFF
> SET CONCAT_NULL_YIELDS_NULL ON
> SET ANSI_NULLS ON
> SET ANSI_PADDING ON
> SET ANSI_WARNINGS ON
> COMMIT
> GO
> CREATE VIEW vw_MyView
> WITH SCHEMABINDING
> AS
> SELECT Col1, Col2 FROM dbo.MyTable WHERECol2 IS NOT NULL
> GO
> /* -- end -- */
> and then added the constraint to the new view
> /* -- start -- */
> CREATE UNIQUE CLUSTERED INDEX AK_MyTable_Constraint1 ON
> vw_MyView(Col1, Col2)
> GO
> /* -- end -- */
> I thought we were doing fine, 'til we started running some DELETE
> stored procedures and got the above error. The error also cited
> ARITHABORT as an incorrect setting until we ran this script:
> /* -- start -- */
> USE master
> DECLARE @.value int
> SELECT @.value = value FROM syscurconfigs
> WHERE config = 1534
> SET @.value = @.value | 64
> EXEC sp_configure 'user options', @.value
> RECONFIGURE
> /* -- end -- */
> TIA to anyone kind enough to shed some light on this for me. Is there
> something we should have done differently in creating the view and
> index? If not, what's the procedure for working through these
> settings errors?
> I've read through some other threads on this subject, but didn't
> really find what I was looking for. Thanks again for any help. Would
> be appreciated.
> -matt|||Thank you all for your responses. I was able to get past the error by
adding

SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS ON
GO

to the top of my trouble Stored Procedures in EM. What a maintainance
nightmare! We make all our changes to DB table structure using change
scripts, so that we can execute the batch of scripts on any of our
development/test/production databases. These manual changes needed to
make a new view work definitely monkeys things up. I suppose I'm going
to have to give this some more thought.

I'm surprised this is not a larger issue. Leads me to wonder what I'm
doing wrong...

thanks again,
-matt

"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message news:<eIuw$yJnDHA.1072@.TK2MSFTNGP09.phx.gbl>...
> Hi Matt
> As Doug and Simon have said, stored procedures created with certain SET
> options enabled will always run with those options, even if you SET them
> differently in the batch that calls the procedure. The only two that are
> stored this way are "ANSI_NULLS" and "QUOTED_IDENTIFIER". I call these
> 'sticky' options, because their values 'stick' to the stored procedure.
> Since these are the two you are getting messages about, it seems likely that
> your procedure was created with the wrong values for these options,.
> You can verify whether these options are set with the procedure by using the
> OBJECTPROPERTY FUNCTION:
> SELECT OBJECTPROPERTY(object_id('proc name'), 'ExecIsAnsiNullsOn' )
> SELECT OBJECTPROPERTY(object_id('proc name'), 'ExecIsQuotedIdentOn')
> If the functions return 1, the property was set, if they return 0, it was
> NOT set for the procedure, and you MUST recreate the procedure to use it
> with an indexed view.
> (If the function returns NULL, it means you typed something wrong. :-) )
> --
> HTH
> ------
> Kalen Delaney
> SQL Server MVP
> www.SolidQualityLearning.com
>
> "Matt Rink" <matty2112@.hotmail.com> wrote in message
> news:1b11065c.0310262201.4f2ba70a@.posting.google.c om...
> > Getting an "incorrect settings: 'ANSI_NULLS., QUOTED_IDENTIFIER'."
> > error after creating a view.
> > We wanted a composite unique constraint that ignored nulls, so we set
> > up a view using the following script:
> > /* -- start -- */
> > BEGIN TRANSACTION
> > SET QUOTED_IDENTIFIER ON
> > SET ARITHABORT ON
> > SET NUMERIC_ROUNDABORT OFF
> > SET CONCAT_NULL_YIELDS_NULL ON
> > SET ANSI_NULLS ON
> > SET ANSI_PADDING ON
> > SET ANSI_WARNINGS ON
> > COMMIT
> > GO
> > CREATE VIEW vw_MyView
> > WITH SCHEMABINDING
> > AS
> > SELECT Col1, Col2 FROM dbo.MyTable WHERECol2 IS NOT NULL
> > GO
> > /* -- end -- */
> > and then added the constraint to the new view
> > /* -- start -- */
> > CREATE UNIQUE CLUSTERED INDEX AK_MyTable_Constraint1 ON
> > vw_MyView(Col1, Col2)
> > GO
> > /* -- end -- */
> > I thought we were doing fine, 'til we started running some DELETE
> > stored procedures and got the above error. The error also cited
> > ARITHABORT as an incorrect setting until we ran this script:
> > /* -- start -- */
> > USE master
> > DECLARE @.value int
> > SELECT @.value = value FROM syscurconfigs
> > WHERE config = 1534
> > SET @.value = @.value | 64
> > EXEC sp_configure 'user options', @.value
> > RECONFIGURE
> > /* -- end -- */
> > TIA to anyone kind enough to shed some light on this for me. Is there
> > something we should have done differently in creating the view and
> > index? If not, what's the procedure for working through these
> > settings errors?
> > I've read through some other threads on this subject, but didn't
> > really find what I was looking for. Thanks again for any help. Would
> > be appreciated.
> > -matt

Incorrect Schedule Displayed

Hi,
I am creating a data driven subscription via code using a shared schedule
and it seems fine, but when I view the subscription in Report Manager it
shows the wrong schedule.
I have checked the MatchData field in the Subscriptions table and the
ScheduleID in the ReportSchedules table and both of these have the correct
ID.
any ideas?
thanks
MattOh, I should add that the subscription runs correctly. It just displays a
different schedule to the one I have assigned on the "Specify When the
subscription is processed." page. Note, if I set the schedule here, it
seems to remember it.
thanks again
"Matt" <NoSpam:Matthew.Moran@.Computercorp.com.au> wrote in message
news:O40uAJ2gEHA.712@.TK2MSFTNGP09.phx.gbl...
> Hi,
> I am creating a data driven subscription via code using a shared schedule
> and it seems fine, but when I view the subscription in Report Manager it
> shows the wrong schedule.
> I have checked the MatchData field in the Subscriptions table and the
> ScheduleID in the ReportSchedules table and both of these have the correct
> ID.
> any ideas?
> thanks
> Matt
>|||Is it possible for you to share your code? You can send it directly to me
if you want and I can take a look. Just remove the online from my address.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Matt" <NoSpam:Matthew.Moran@.Computercorp.com.au> wrote in message
news:#NVQ#z2gEHA.1972@.TK2MSFTNGP09.phx.gbl...
> Oh, I should add that the subscription runs correctly. It just displays a
> different schedule to the one I have assigned on the "Specify When the
> subscription is processed." page. Note, if I set the schedule here, it
> seems to remember it.
> thanks again
>
> "Matt" <NoSpam:Matthew.Moran@.Computercorp.com.au> wrote in message
> news:O40uAJ2gEHA.712@.TK2MSFTNGP09.phx.gbl...
> > Hi,
> >
> > I am creating a data driven subscription via code using a shared
schedule
> > and it seems fine, but when I view the subscription in Report Manager it
> > shows the wrong schedule.
> >
> > I have checked the MatchData field in the Subscriptions table and the
> > ScheduleID in the ReportSchedules table and both of these have the
correct
> > ID.
> >
> > any ideas?
> >
> > thanks
> >
> > Matt
> >
> >
>

Wednesday, March 7, 2012

Included columns in index.. performance implications ?

How detrimental is it to create multiple indexes that have included columns
as opposed to creating composite indexes that include that all those columns
?
I want to add the index with included columns but also concerned about
slowness in performance on writes. Either way I want to create the index..
the only difference will be whether I decide to have those included columns
or not..
ThanksIt is not really a performance decision. It depends if those columns will be
used, for example, on the WHERE clause or just on the SELECT clause. If thes
e
columns will be listed only in the SELECT clause then use included columns.
If you are going to use those columns as a search criteria then included
columns would not help.
Regarding performance, include columns are better because they are only
stored at the leaf level of the index.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:

> How detrimental is it to create multiple indexes that have included column
s
> as opposed to creating composite indexes that include that all those colum
ns
> ?
> I want to add the index with included columns but also concerned about
> slowness in performance on writes. Either way I want to create the index.
.
> the only difference will be whether I decide to have those included column
s
> or not..
> Thanks
>

Included columns in index.. performance implications ?

How detrimental is it to create multiple indexes that have included columns
as opposed to creating composite indexes that include that all those columns
?
I want to add the index with included columns but also concerned about
slowness in performance on writes. Either way I want to create the index..
the only difference will be whether I decide to have those included columns
or not..
Thanks
It is not really a performance decision. It depends if those columns will be
used, for example, on the WHERE clause or just on the SELECT clause. If these
columns will be listed only in the SELECT clause then use included columns.
If you are going to use those columns as a search criteria then included
columns would not help.
Regarding performance, include columns are better because they are only
stored at the leaf level of the index.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:

> How detrimental is it to create multiple indexes that have included columns
> as opposed to creating composite indexes that include that all those columns
> ?
> I want to add the index with included columns but also concerned about
> slowness in performance on writes. Either way I want to create the index..
> the only difference will be whether I decide to have those included columns
> or not..
> Thanks
>

Included columns in index.. performance implications ?

How detrimental is it to create multiple indexes that have included columns
as opposed to creating composite indexes that include that all those columns
?
I want to add the index with included columns but also concerned about
slowness in performance on writes. Either way I want to create the index..
the only difference will be whether I decide to have those included columns
or not..
ThanksIt is not really a performance decision. It depends if those columns will be
used, for example, on the WHERE clause or just on the SELECT clause. If these
columns will be listed only in the SELECT clause then use included columns.
If you are going to use those columns as a search criteria then included
columns would not help.
Regarding performance, include columns are better because they are only
stored at the leaf level of the index.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:
> How detrimental is it to create multiple indexes that have included columns
> as opposed to creating composite indexes that include that all those columns
> ?
> I want to add the index with included columns but also concerned about
> slowness in performance on writes. Either way I want to create the index..
> the only difference will be whether I decide to have those included columns
> or not..
> Thanks
>