Datasource = SQL 2000 sp2 (Cross-Database-Ownership Chaining?)

We have a report in RS 2005, data source uses Windows Integrated Security,
Initial Catalog is the database where the stored procedure is. The stored
procedure selects data from a different database on the server. This server
is running SQL Server 200 sp2 (so pre-Cross-Database-Ownership Chaining
option). The users can execute the stored procedure fine so it does not seem
to be a permissions issue to the data. The Report runs fine FROM the Report
Server. But, if I try to run the report from a different machine, I get:
An error has occurred during report processing. (rsProcessingAborted)
Cannot create a connection to data source 'DataSourceNameIsHere'.
(rsErrorOpeningConnection)
For more information about this error navigate to the report server on the
local server machine, or enable remote errors
The report also runs fine if we don't use Windows Integrated Security. The
report runs fine if the datasource (both databases) are on SQL2000 sp3. Is
there anything that we can do to get this working on SQL2000 sp2? I'm not
sure that all systems on this server are supported on sp3 (3a or 4). It hosts
several databases from purchased products.I found this in the Reporting Services Log:
ERROR: Throwing
Microsoft.ReportingServices.ReportProcessing.ReportProcessingException:
Cannot create a connection to data source 'DataSourceNameIsHere'., ;
Info:
Microsoft.ReportingServices.ReportProcessing.ReportProcessingException:
Cannot create a connection to data source 'DataSourceNameIsHere'. -->
System.Data.SqlClient.SqlException: Login failed for user 'NT
AUTHORITY\ANONYMOUS LOGON'.
Michelle
"Michelle" wrote:
> We have a report in RS 2005, data source uses Windows Integrated Security,
> Initial Catalog is the database where the stored procedure is. The stored
> procedure selects data from a different database on the server. This server
> is running SQL Server 200 sp2 (so pre-Cross-Database-Ownership Chaining
> option). The users can execute the stored procedure fine so it does not seem
> to be a permissions issue to the data. The Report runs fine FROM the Report
> Server. But, if I try to run the report from a different machine, I get:
> An error has occurred during report processing. (rsProcessingAborted)
> Cannot create a connection to data source 'DataSourceNameIsHere'.
> (rsErrorOpeningConnection)
> For more information about this error navigate to the report server on the
> local server machine, or enable remote errors
> The report also runs fine if we don't use Windows Integrated Security. The
> report runs fine if the datasource (both databases) are on SQL2000 sp3. Is
> there anything that we can do to get this working on SQL2000 sp2? I'm not
> sure that all systems on this server are supported on sp3 (3a or 4). It hosts
> several databases from purchased products.sql

Datasource = SQL 2000 sp2 (Cross-Database-Ownership Chaining?)

We have a report in RS 2005, data source uses Windows Integrated

Security, Initial Catalog is the database where the stored procedure

is. The stored procedure selects data from a different database on the

server. This server is running SQL Server 200 sp2 (so

pre-Cross-Database-Ownership Chaining option). The users can execute

the stored procedure fine so it does not seem to be a permissions issue

to the data. The Report runs fine FROM the Report Server. But, if I try

to run the report from a different machine, I get:

An error has occurred during report processing. (rsProcessingAborted)

Cannot create a connection to data source 'DataSourceNameIsHere'. (rsErrorOpeningConnection)

For more information about this error navigate to the report server on the local server machine, or enable remote errors

The report also runs fine if we don't use Windows Integrated Security.

The report runs fine if the datasource (both databases) are on SQL2000

sp3. Is there anything that we can do to get this working on SQL2000

sp2? I'm not sure that all systems on this server are supported on sp3

(3a or 4). It hosts several databases from purchased products.I found this in the Reporting Services Log:

ERROR: Throwing

Microsoft.ReportingServices.ReportProcessing.ReportProcessingException:

Cannot create a connection to data source 'DataSourceNameIsHere'., ;

Info: Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Cannot create a connection to data source 'DataSourceNameIsHere'. > System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

Michelle

Datasource = SQL 2000 sp2 (Cross-Database-Ownership Chaining?)

We have a report in RS 2005, data source uses Windows Integrated

Security, Initial Catalog is the database where the stored procedure

is. The stored procedure selects data from a different database on the

server. This server is running SQL Server 200 sp2 (so

pre-Cross-Database-Ownership Chaining option). The users can execute

the stored procedure fine so it does not seem to be a permissions issue

to the data. The Report runs fine FROM the Report Server. But, if I try

to run the report from a different machine, I get:

An error has occurred during report processing. (rsProcessingAborted)

Cannot create a connection to data source 'DataSourceNameIsHere'. (rsErrorOpeningConnection)

For more information about this error navigate to the report server on the local server machine, or enable remote errors

The report also runs fine if we don't use Windows Integrated Security.

The report runs fine if the datasource (both databases) are on SQL2000

sp3. Is there anything that we can do to get this working on SQL2000

sp2? I'm not sure that all systems on this server are supported on sp3

(3a or 4). It hosts several databases from purchased products.I found this in the Reporting Services Log:

ERROR: Throwing

Microsoft.ReportingServices.ReportProcessing.ReportProcessingException:

Cannot create a connection to data source 'DataSourceNameIsHere'., ;

Info: Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Cannot create a connection to data source 'DataSourceNameIsHere'. > System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

Michelle

DATABASE= or INITIAL CATALOG=?

I'm setting up a DSN for a new SQL Server install, and had some problems with
an existing Access app. Every query resulted in an "object not found", and
after a little poking about it became clear that it was because the app was
connecting to "master" instead of our database.
The connection string in Access used "Database=[our database name]". Does
this actually work? Or did the app only work in the past because the default
database for that login was set to ours?
Is there a difference between DATABASE (which I inherited) and INITIAL
CATALOG?
Yes, Database=YourDatabase does actually work.
Initial catalog is generally used when connecting with an
OLE DB provider.
Database is generally used when connecting with an ODBC
driver.
The following is a good resource for connection strings:
http://www.able-consulting.com/ADO_Conn.htm
-Sue
On Wed, 24 Nov 2004 07:37:35 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:

>I'm setting up a DSN for a new SQL Server install, and had some problems with
>an existing Access app. Every query resulted in an "object not found", and
>after a little poking about it became clear that it was because the app was
>connecting to "master" instead of our database.
>The connection string in Access used "Database=[our database name]". Does
>this actually work? Or did the app only work in the past because the default
>database for that login was set to ours?
>Is there a difference between DATABASE (which I inherited) and INITIAL
>CATALOG?
|||"Sue Hoegemeier" wrote:

> Yes, Database=YourDatabase does actually work.
> Initial catalog is generally used when connecting with an
> OLE DB provider.
Hmmm. That being the case can you suggest any other reason for this problem?
The application logs into the correct server and attaches to master, even
though I say database=mydatabase in the connection string.
|||Using DSNs and connections strings is kind of a waste in my
opinion and can make the issues more convoluted. I have no
idea how the DSN and connection strings are being used but I
would just get rid of the DSN. You introduce maintenance
issues as well as you have your connection string in a DSN
and in code. So I'd eliminate that and just use dsn-less
connections.
Make sure the user exists in the database and can actually
access the database.
-Sue
On Wed, 24 Nov 2004 08:37:04 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:

>"Sue Hoegemeier" wrote:
>
>Hmmm. That being the case can you suggest any other reason for this problem?
>The application logs into the correct server and attaches to master, even
>though I say database=mydatabase in the connection string.

DATABASE= or INITIAL CATALOG=?

I'm setting up a DSN for a new SQL Server install, and had some problems wit
h
an existing Access app. Every query resulted in an "object not found", and
after a little poking about it became clear that it was because the app was
connecting to "master" instead of our database.
The connection string in Access used "Database=[our database name]". Doe
s
this actually work? Or did the app only work in the past because the default
database for that login was set to ours?
Is there a difference between DATABASE (which I inherited) and INITIAL
CATALOG?Yes, Database=YourDatabase does actually work.
Initial catalog is generally used when connecting with an
OLE DB provider.
Database is generally used when connecting with an ODBC
driver.
The following is a good resource for connection strings:
http://www.able-consulting.com/ADO_Conn.htm
-Sue
On Wed, 24 Nov 2004 07:37:35 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:

>I'm setting up a DSN for a new SQL Server install, and had some problems wi
th
>an existing Access app. Every query resulted in an "object not found", and
>after a little poking about it became clear that it was because the app was
>connecting to "master" instead of our database.
>The connection string in Access used "Database=[our database name]". Do
es
>this actually work? Or did the app only work in the past because the defaul
t
>database for that login was set to ours?
>Is there a difference between DATABASE (which I inherited) and INITIAL
>CATALOG?|||"Sue Hoegemeier" wrote:

> Yes, Database=YourDatabase does actually work.
> Initial catalog is generally used when connecting with an
> OLE DB provider.
Hmmm. That being the case can you suggest any other reason for this problem?
The application logs into the correct server and attaches to master, even
though I say database=mydatabase in the connection string.|||Using DSNs and connections strings is kind of a waste in my
opinion and can make the issues more convoluted. I have no
idea how the DSN and connection strings are being used but I
would just get rid of the DSN. You introduce maintenance
issues as well as you have your connection string in a DSN
and in code. So I'd eliminate that and just use dsn-less
connections.
Make sure the user exists in the database and can actually
access the database.
-Sue
On Wed, 24 Nov 2004 08:37:04 -0800, Maury Markowitz
<MauryMarkowitz@.discussions.microsoft.com> wrote:

>"Sue Hoegemeier" wrote:
>
>Hmmm. That being the case can you suggest any other reason for this problem
?
>The application logs into the correct server and attaches to master, even
>though I say database=mydatabase in the connection string.