Error installing SQL 2005 Reporting Services September CTP

When installing the September SQL 2005 CTP, the installation of
Reporting Services fails with the message: "The setup has encountered
an unexpected error while Setting reporting service and share point
exclusion path. The error is: Fatal error during installation."
Here's the section from the log:
---
<Func Name='LaunchFunction'>
Function=Do_RSSetSharePointExclusionPath
<Func Name='GetCAContext'>
<EndFunc Name='GetCAContext' Return='T' GetLastError='0'>
Doing Action: Do_RSSetSharePointExclusionPath
PerfTime Start: Do_RSSetSharePointExclusionPath : Thu Oct 06 12:48:54
2005
<Func Name='Do_RSSetSharePointExclusionPath'>
Error Code: 0x80077374 (29556)
Windows Error Text: Source File Name: sqlca\sqliisca.cpp
Compiler Timestamp: Tue Aug 30 21:43:12 2005
Function Name: Do_RSSetSharePointExclusionPath
Source Line Number: 840
Error Code: 29556
MSI (s) (88!68) [12:57:42:934]: Product: Microsoft SQL Server 2005
Reporting Services CTP -- Error 29528. The setup has encountered an
unexpected error while Setting reporting service and share point
exclusion path. The error is: Fatal error during installation.
Error 29528. The setup has encountered an unexpected error while
Setting reporting service and share point exclusion path. The error is:
Fatal error during installation.
--
Sharepoint (not sure if that's what is referred to by "share point" up
above) is installed and working on the box in question. Any thoughts?
KenWell, I appear to have worked around it by uninstalling SharePoint
(both the "portal" and the "services" flavors). I reran setup, and it
worked that time. Luckily I didn't need SP on this box (yeah, yeah,
and it's still beta . . . )
Ken|||On 6 Oct 2005 13:11:22 -0700, smithkl42@.hotmail.com wrote:
>When installing the September SQL 2005 CTP, the installation of
>Reporting Services fails with the message: "The setup has encountered
>an unexpected error while Setting reporting service and share point
>exclusion path. The error is: Fatal error during installation."
>Here's the section from the log:
>---
><Func Name='LaunchFunction'>
>Function=Do_RSSetSharePointExclusionPath
><Func Name='GetCAContext'>
><EndFunc Name='GetCAContext' Return='T' GetLastError='0'>
>Doing Action: Do_RSSetSharePointExclusionPath
>PerfTime Start: Do_RSSetSharePointExclusionPath : Thu Oct 06 12:48:54
>2005
><Func Name='Do_RSSetSharePointExclusionPath'>
> Error Code: 0x80077374 (29556)
>Windows Error Text: Source File Name: sqlca\sqliisca.cpp
>Compiler Timestamp: Tue Aug 30 21:43:12 2005
> Function Name: Do_RSSetSharePointExclusionPath
>Source Line Number: 840
>
>Error Code: 29556
>MSI (s) (88!68) [12:57:42:934]: Product: Microsoft SQL Server 2005
>Reporting Services CTP -- Error 29528. The setup has encountered an
>unexpected error while Setting reporting service and share point
>exclusion path. The error is: Fatal error during installation.
>
>Error 29528. The setup has encountered an unexpected error while
>Setting reporting service and share point exclusion path. The error is:
>Fatal error during installation.
>--
>Sharepoint (not sure if that's what is referred to by "share point" up
>above) is installed and working on the box in question. Any thoughts?
>Ken
Ken,
I tried a few times to get Reporting Services 2005 and Windows
SharePoint Services 2 working on the same box and failed with earlier
builds.
The specific problem you are seeing, I guess, is that say
http://localhost/reports and http://localhost/reportserver need to be
excluded paths (if I remember the terminology correctly in WSS2) on a
SharePoint server.
You need to find the Managed Paths screen to create the excluded
paths.
That's the first step, I think.
Andrew Watt
MVP - InfoPath

Error in Inintial Replication

I'm Replicating from one SQL200 db to another on our LAN. The target db is
blank, but on some of the tables, it fails with:
Could not bulk insert. Bulk data stream was incorrectly specified as sorted.
(Source: STAN (Data source); Error number: 4819)
I've verified that the collation and sort order are the same. Any ideas?
Jeff
Jeff,
Make sure the publisher and subscriber have the same collations - this
is normally due to differing collations.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
Jeff Dillon wrote:
> I'm Replicating from one SQL200 db to another on our LAN. The target db is
> blank, but on some of the tables, it fails with:
> Could not bulk insert. Bulk data stream was incorrectly specified as sorted.
> (Source: STAN (Data source); Error number: 4819)
> I've verified that the collation and sort order are the same. Any ideas?
> Jeff
>
|||As I stated, they do have the same collation. Even using an empty database
as the subscriber causes this. So far, it appears the tables that are
failing have text columns.
I did a Google search on this, and the common reply is to check collation.
In neither of the 2 cases I found was collation the issue. It was never
resolved. Appears to be a bug.
I run sp_helpsort in each database, and it returns the same results. Is
there somewhere else I need to check?
Jeff
"Mark Allison" <marka@.no.tinned.meat.mvps.org> wrote in message
news:O8JpwvUpEHA.2948@.TK2MSFTNGP11.phx.gbl...[vbcol=seagreen]
> Jeff,
> Make sure the publisher and subscriber have the same collations - this
> is normally due to differing collations.
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602m.html
>
> Jeff Dillon wrote:
is[vbcol=seagreen]
sorted.[vbcol=seagreen]
|||I found the problem. I had a wide clustered index (by wide I mean several
fields, including varchar).
I changed it to non-clustered, and it works. Bug? maybe...
Jeff
"Jeff Dillon" <jeff@.removeemergencyreporting.com> wrote in message
news:eEnFD0WpEHA.2612@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> As I stated, they do have the same collation. Even using an empty database
> as the subscriber causes this. So far, it appears the tables that are
> failing have text columns.
> I did a Google search on this, and the common reply is to check collation.
> In neither of the 2 cases I found was collation the issue. It was never
> resolved. Appears to be a bug.
> I run sp_helpsort in each database, and it returns the same results. Is
> there somewhere else I need to check?
> Jeff
> "Mark Allison" <marka@.no.tinned.meat.mvps.org> wrote in message
> news:O8JpwvUpEHA.2948@.TK2MSFTNGP11.phx.gbl...
db[vbcol=seagreen]
> is
> sorted.
ideas?
>

Error in Inintial Replication

I'm Replicating from one SQL200 db to another on our LAN. The target db is
blank, but on some of the tables, it fails with:
Could not bulk insert. Bulk data stream was incorrectly specified as sorted.
(Source: STAN (Data source); Error number: 4819)
I've verified that the collation and sort order are the same. Any ideas?
JeffJeff,
Make sure the publisher and subscriber have the same collations - this
is normally due to differing collations.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
Jeff Dillon wrote:
> I'm Replicating from one SQL200 db to another on our LAN. The target db is
> blank, but on some of the tables, it fails with:
> Could not bulk insert. Bulk data stream was incorrectly specified as sorted.
> (Source: STAN (Data source); Error number: 4819)
> I've verified that the collation and sort order are the same. Any ideas?
> Jeff
>|||As I stated, they do have the same collation. Even using an empty database
as the subscriber causes this. So far, it appears the tables that are
failing have text columns.
I did a Google search on this, and the common reply is to check collation.
In neither of the 2 cases I found was collation the issue. It was never
resolved. Appears to be a bug.
I run sp_helpsort in each database, and it returns the same results. Is
there somewhere else I need to check?
Jeff
"Mark Allison" <marka@.no.tinned.meat.mvps.org> wrote in message
news:O8JpwvUpEHA.2948@.TK2MSFTNGP11.phx.gbl...
> Jeff,
> Make sure the publisher and subscriber have the same collations - this
> is normally due to differing collations.
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602m.html
>
> Jeff Dillon wrote:
> > I'm Replicating from one SQL200 db to another on our LAN. The target db
is
> > blank, but on some of the tables, it fails with:
> >
> > Could not bulk insert. Bulk data stream was incorrectly specified as
sorted.
> > (Source: STAN (Data source); Error number: 4819)
> >
> > I've verified that the collation and sort order are the same. Any ideas?
> >
> > Jeff
> >
> >|||I found the problem. I had a wide clustered index (by wide I mean several
fields, including varchar).
I changed it to non-clustered, and it works. Bug? maybe...
Jeff
"Jeff Dillon" <jeff@.removeemergencyreporting.com> wrote in message
news:eEnFD0WpEHA.2612@.TK2MSFTNGP15.phx.gbl...
> As I stated, they do have the same collation. Even using an empty database
> as the subscriber causes this. So far, it appears the tables that are
> failing have text columns.
> I did a Google search on this, and the common reply is to check collation.
> In neither of the 2 cases I found was collation the issue. It was never
> resolved. Appears to be a bug.
> I run sp_helpsort in each database, and it returns the same results. Is
> there somewhere else I need to check?
> Jeff
> "Mark Allison" <marka@.no.tinned.meat.mvps.org> wrote in message
> news:O8JpwvUpEHA.2948@.TK2MSFTNGP11.phx.gbl...
> > Jeff,
> >
> > Make sure the publisher and subscriber have the same collations - this
> > is normally due to differing collations.
> > --
> > Mark Allison, SQL Server MVP
> > http://www.markallison.co.uk
> >
> > Looking for a SQL Server replication book?
> > http://www.nwsu.com/0974973602m.html
> >
> >
> > Jeff Dillon wrote:
> > > I'm Replicating from one SQL200 db to another on our LAN. The target
db
> is
> > > blank, but on some of the tables, it fails with:
> > >
> > > Could not bulk insert. Bulk data stream was incorrectly specified as
> sorted.
> > > (Source: STAN (Data source); Error number: 4819)
> > >
> > > I've verified that the collation and sort order are the same. Any
ideas?
> > >
> > > Jeff
> > >
> > >
>

Error Handling with openrowset

I am using openrowset to interact with some fox pro tables.
I want to be able do error handling if the openrowset quiery fails.
When the quiery gets and error it terminates and does not seem to return and
error status.
Here is a code sample.
Update openrowset('MSDASQL',
'Driver={Microsoft Visual FoxPro
Driver};UID=;PWD=;SourceDB=\\dataserver\prod\apps\ tele\;SourceType=DBF;Exclusive=No;Background
Fetch=Yes;Collate=Machine;Null=Yes;Deleted=Yes',
'select PROMO_CODE from prospect_conf
where area_code+home_phone in (select parea_code+phome_phon from
prospext_conf
where ctod(misc5) = date())')
set promo_code = LEft(promo_code,3)+'0'
Thanks in advance
Regarding Trapping the error from an OpenRowset failure.
I have had similar problems using OpenRowset with FoxPro tables, and found the workaround to be as follows.
1. Build the Openrowset query inside a stored procedure.
2. Call that procedure from inside a parameterised DTS package (Exec usp_Procname ?,?,?)
3. Call the DTS package from another stored procedure.
The DTS package will return a trapable error, so if you are trying to do some type of batch processing your process can continue on.
Admittedly it's a bit convoluted, but it works.

Error Handling in SQL?

Hi there,
A insert query fails because of the erroneous data (primary key violation,
data type mismatch, etc). This insert statement is in the middle of a stored
procedure, which is part of a large system. We don't have the error handling
code in the system. Whenver error happens, it simply exits.
The big problem is that for such case, one bad record in the insert query
can take down the entire system.
It will be ideal if this query can automatically re-run when it failed in
the first run and filter out the "problem" records and succeed in the second
attempt without taking down the entire system.
Any idea, sample code or suggestion are highly appreciated.
LX
http://www.sommarskog.se/error-handling-I.html
http://www.sommarskog.se/error-handling-II.html
will get you started.
Jacco Schalkwijk
SQL Server MVP
"FLX" <nospam@.hotmail.com> wrote in message
news:%23qlKbtXeEHA.724@.TK2MSFTNGP10.phx.gbl...
> Hi there,
> A insert query fails because of the erroneous data (primary key violation,
> data type mismatch, etc). This insert statement is in the middle of a
> stored
> procedure, which is part of a large system. We don't have the error
> handling
> code in the system. Whenver error happens, it simply exits.
> The big problem is that for such case, one bad record in the insert query
> can take down the entire system.
> It will be ideal if this query can automatically re-run when it failed in
> the first run and filter out the "problem" records and succeed in the
> second
> attempt without taking down the entire system.
> Any idea, sample code or suggestion are highly appreciated.
> LX
>

Error Handling in SQL?

Hi there,
A insert query fails because of the erroneous data (primary key violation,
data type mismatch, etc). This insert statement is in the middle of a stored
procedure, which is part of a large system. We don't have the error handling
code in the system. Whenver error happens, it simply exits.
The big problem is that for such case, one bad record in the insert query
can take down the entire system.
It will be ideal if this query can automatically re-run when it failed in
the first run and filter out the "problem" records and succeed in the second
attempt without taking down the entire system.
Any idea, sample code or suggestion are highly appreciated.
LXhttp://www.sommarskog.se/error-handling-I.html
http://www.sommarskog.se/error-handling-II.html
will get you started.
Jacco Schalkwijk
SQL Server MVP
"FLX" <nospam@.hotmail.com> wrote in message
news:%23qlKbtXeEHA.724@.TK2MSFTNGP10.phx.gbl...
> Hi there,
> A insert query fails because of the erroneous data (primary key violation,
> data type mismatch, etc). This insert statement is in the middle of a
> stored
> procedure, which is part of a large system. We don't have the error
> handling
> code in the system. Whenver error happens, it simply exits.
> The big problem is that for such case, one bad record in the insert query
> can take down the entire system.
> It will be ideal if this query can automatically re-run when it failed in
> the first run and filter out the "problem" records and succeed in the
> second
> attempt without taking down the entire system.
> Any idea, sample code or suggestion are highly appreciated.
> LX
>|||data type mis-match will abort processing, primary key errors won't. Jacco's
already pointed you out to the best articles available on tsql error
handling but I'd add that you really need to handle error conditions in your
client application if you want re-try logic. It's the only place where
that's even possible if TSQL aborts processing..
HTH
Regards,
Greg Linwood
SQL Server MVP
"FLX" <nospam@.hotmail.com> wrote in message
news:%23qlKbtXeEHA.724@.TK2MSFTNGP10.phx.gbl...
> Hi there,
> A insert query fails because of the erroneous data (primary key violation,
> data type mismatch, etc). This insert statement is in the middle of a
stored
> procedure, which is part of a large system. We don't have the error
handling
> code in the system. Whenver error happens, it simply exits.
> The big problem is that for such case, one bad record in the insert query
> can take down the entire system.
> It will be ideal if this query can automatically re-run when it failed in
> the first run and filter out the "problem" records and succeed in the
second
> attempt without taking down the entire system.
> Any idea, sample code or suggestion are highly appreciated.
> LX
>

Error Handling in SQL?

Hi there,
A insert query fails because of the erroneous data (primary key violation,
data type mismatch, etc). This insert statement is in the middle of a stored
procedure, which is part of a large system. We don't have the error handling
code in the system. Whenver error happens, it simply exits.
The big problem is that for such case, one bad record in the insert query
can take down the entire system.
It will be ideal if this query can automatically re-run when it failed in
the first run and filter out the "problem" records and succeed in the second
attempt without taking down the entire system.
Any idea, sample code or suggestion are highly appreciated.
LXhttp://www.sommarskog.se/error-handling-I.html
http://www.sommarskog.se/error-handling-II.html
will get you started.
--
Jacco Schalkwijk
SQL Server MVP
"FLX" <nospam@.hotmail.com> wrote in message
news:%23qlKbtXeEHA.724@.TK2MSFTNGP10.phx.gbl...
> Hi there,
> A insert query fails because of the erroneous data (primary key violation,
> data type mismatch, etc). This insert statement is in the middle of a
> stored
> procedure, which is part of a large system. We don't have the error
> handling
> code in the system. Whenver error happens, it simply exits.
> The big problem is that for such case, one bad record in the insert query
> can take down the entire system.
> It will be ideal if this query can automatically re-run when it failed in
> the first run and filter out the "problem" records and succeed in the
> second
> attempt without taking down the entire system.
> Any idea, sample code or suggestion are highly appreciated.
> LX
>|||data type mis-match will abort processing, primary key errors won't. Jacco's
already pointed you out to the best articles available on tsql error
handling but I'd add that you really need to handle error conditions in your
client application if you want re-try logic. It's the only place where
that's even possible if TSQL aborts processing..
HTH
Regards,
Greg Linwood
SQL Server MVP
"FLX" <nospam@.hotmail.com> wrote in message
news:%23qlKbtXeEHA.724@.TK2MSFTNGP10.phx.gbl...
> Hi there,
> A insert query fails because of the erroneous data (primary key violation,
> data type mismatch, etc). This insert statement is in the middle of a
stored
> procedure, which is part of a large system. We don't have the error
handling
> code in the system. Whenver error happens, it simply exits.
> The big problem is that for such case, one bad record in the insert query
> can take down the entire system.
> It will be ideal if this query can automatically re-run when it failed in
> the first run and filter out the "problem" records and succeed in the
second
> attempt without taking down the entire system.
> Any idea, sample code or suggestion are highly appreciated.
> LX
>