Datasource and Catalog

Hi all,

I accidentally deleted the datasource including the root data source and catalog from reporting services running in SQL server 2005. As a result, my reports didn't work. What should I do? Thanks!

lk_spec

Create a new datasource and link the report to the new datasources. What do you mean by catalog ?

HTH, jens Suessmeyer.

http://www.sqlserver2005.de|||

Thanks for you reply!

The data source was created dynamiclly through web services and SOAP. Before I deleted the data source, my reports worked fine. After that, however, it didn't work. I wonder if it's related to the root data source or something. Any help is appreciated!

|||The datasource is saved in the RDL as:

<rd:DataSourceID>e80dd27e-83d3-475c-b4c7-81261ee98f08</rd:DataSourceID>

with an ID, I don′t know if you can recover that. I you have the chance to reploy everything, I would go this way.

HTH, Jens Suessmeyer.

http://www.sqlserver2005.de

|||

Jen,

Where did I find the datasource id. I checked the rdl file, but there wasn't such information. I'm really new at this stuff.

|||Did you have a view on the RDL in VS or the RDL in the Report Manager, you can download the RDL in Report Manager by Opening the report > Properties > Edit Report, you will get the RDL file downloaded which contained (in my case) this GUID.

HTH, Jens Suessmeyer.

http.//www.sqlserver2005.de|||

Jen,

Thanks for your reply!

I was able to create a new data source. The problem now is, however, an error message saying that the item "/" cannot be found. The application failed when it tried to FindCatalogItems:

rsws.FindItems(folderName, BooleanOperatorEnum.Or, conditions)

Any help would be appreciated!

lk_spec

|||

If you take regular backup of database than restore the database.

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

DatabaseMetadata methods with catalog parameters now error if current database does not match.

In the v1.2 CTP version, the DatabaseMetadata methods for getting information about objects in a database (i.e. getTables(), getColumns(), ...) errors if your current database connection is in a different database than the object you are quering.

Is this the intended behavior going forward?

In my case I have access to both database A and database B. My current connection is in database A , but I am looking up object in database B.

ResultSet rs = conn.getDatabaseMetadata.getTables("B","dbo","%",{"TABLES" });

[junit] The database name component of the object qualifier must be the name of the current database.
[junit] com.microsoft.sqlserver.jdbc.SQLServerException: The database name component of the object qualifier must be the name of
the current database.
[junit] at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.TDSCommand.execute(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeQueryInternal(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getResultSet(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getResultSet(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getColumns(Unknown Source)

~Mike Hale

Hi Michael,

Do you have a standalone application that will reproduce this problem? If not, allow me some time to author one and investigate.

Regards,

Jaaved Mohammed

|||

I see that there is a bug filed for this issue via Microsoft Connect:

http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=277128

We will investigate and prioritize accordingly.

|||

I am not sure you can do this. This implying that you can access tables from database B when you are connected to database A.

This would imply that your connection can be re-directed to another database. My understanding of how this works is that a connection is to a single (one and only one) SQL database.

If this is possible then I would also expect to be able to joins across databases, which I believe is not possible.

|||Michael, did MS ever tell you when this would be released? I'm having the same problem and would like to get the fix in.
|||

Hi,

Thank you for evaluating the v1.2 CTP and providing feedback.

As Jaaved said earlier, a bug was filed to address this issue. It has since been fixed in internal builds. The next public CTP of the driver, targeted for release later this summer, should contain the fix.

--David Olix [MSFT]

|||

I'm getting the same problem but directly from SQL Server 2005 (SP2)...

In Mangement Studio I'm connected to 'Database_A'

I execute the following SQL:

exec sp_columns
'ViewName'
, 'dbo'
, 'Database_B'

SQL Server returns:

Msg 15250, Level 16, State 1, Procedure sp_columns, Line 24
The database name component of the object qualifier must be the name of the current database.

What the point in providing a database parameter to choose a database if it can only be set to the current database of the connection?

My version is:

Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86) Apr 14 2006 01:12:25 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 1)

|||

I eneded up doing the following as a work around:

exec [Database_B].dbo.sp_columns

'ViewName'

but this isn't ideal as "Database_B" is provided as a parameter to the stored procedure that's executing this code so I have to build some dynamic sql on the fly to execute the statement.

I have no problems with sp_columns_ex when using linked servers so it seems crazy to me that sp_columns doesn't work in the same manner when not linking servers (e.g. "Database_A" and "Database_B" are on the same server)

DatabaseMetadata methods with catalog parameters now error if current database does not match.

In the v1.2 CTP version, the DatabaseMetadata methods for getting information about objects in a database (i.e. getTables(), getColumns(), ...) errors if your current database connection is in a different database than the object you are quering.

Is this the intended behavior going forward?

In my case I have access to both database A and database B. My current connection is in database A , but I am looking up object in database B.

ResultSet rs = conn.getDatabaseMetadata.getTables("B","dbo","%",{"TABLES" });

[junit] The database name component of the object qualifier must be the name of the current database.
[junit] com.microsoft.sqlserver.jdbc.SQLServerException: The database name component of the object qualifier must be the name of
the current database.
[junit] at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.TDSCommand.execute(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeQueryInternal(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getResultSet(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getResultSet(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getColumns(Unknown Source)

~Mike Hale

Hi Michael,

Do you have a standalone application that will reproduce this problem? If not, allow me some time to author one and investigate.

Regards,

Jaaved Mohammed

|||

I see that there is a bug filed for this issue via Microsoft Connect:

http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=277128

We will investigate and prioritize accordingly.

|||

I am not sure you can do this. This implying that you can access tables from database B when you are connected to database A.

This would imply that your connection can be re-directed to another database. My understanding of how this works is that a connection is to a single (one and only one) SQL database.

If this is possible then I would also expect to be able to joins across databases, which I believe is not possible.

|||Michael, did MS ever tell you when this would be released? I'm having the same problem and would like to get the fix in.
|||

Hi,

Thank you for evaluating the v1.2 CTP and providing feedback.

As Jaaved said earlier, a bug was filed to address this issue. It has since been fixed in internal builds. The next public CTP of the driver, targeted for release later this summer, should contain the fix.

--David Olix [MSFT]

|||

I'm getting the same problem but directly from SQL Server 2005 (SP2)...

In Mangement Studio I'm connected to 'Database_A'

I execute the following SQL:

exec sp_columns
'ViewName'
, 'dbo'
, 'Database_B'

SQL Server returns:

Msg 15250, Level 16, State 1, Procedure sp_columns, Line 24
The database name component of the object qualifier must be the name of the current database.

What the point in providing a database parameter to choose a database if it can only be set to the current database of the connection?

My version is:

Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86) Apr 14 2006 01:12:25 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 1)

|||

I eneded up doing the following as a work around:

exec [Database_B].dbo.sp_columns

'ViewName'

but this isn't ideal as "Database_B" is provided as a parameter to the stored procedure that's executing this code so I have to build some dynamic sql on the fly to execute the statement.

I have no problems with sp_columns_ex when using linked servers so it seems crazy to me that sp_columns doesn't work in the same manner when not linking servers (e.g. "Database_A" and "Database_B" are on the same server)

DatabaseMetadata methods with catalog parameters now error if current database does not match.

In the v1.2 CTP version, the DatabaseMetadata methods for getting information about objects in a database (i.e. getTables(), getColumns(), ...) errors if your current database connection is in a different database than the object you are quering.

Is this the intended behavior going forward?

In my case I have access to both database A and database B. My current connection is in database A , but I am looking up object in database B.

ResultSet rs = conn.getDatabaseMetadata.getTables("B","dbo","%",{"TABLES" });

[junit] The database name component of the object qualifier must be the name of the current database.
[junit] com.microsoft.sqlserver.jdbc.SQLServerException: The database name component of the object qualifier must be the name of
the current database.
[junit] at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.TDSCommand.execute(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeQueryInternal(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getResultSet(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getResultSet(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getColumns(Unknown Source)

~Mike Hale

Hi Michael,

Do you have a standalone application that will reproduce this problem? If not, allow me some time to author one and investigate.

Regards,

Jaaved Mohammed

|||

I see that there is a bug filed for this issue via Microsoft Connect:

http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=277128

We will investigate and prioritize accordingly.

|||

I am not sure you can do this. This implying that you can access tables from database B when you are connected to database A.

This would imply that your connection can be re-directed to another database. My understanding of how this works is that a connection is to a single (one and only one) SQL database.

If this is possible then I would also expect to be able to joins across databases, which I believe is not possible.

|||Michael, did MS ever tell you when this would be released? I'm having the same problem and would like to get the fix in.
|||

Hi,

Thank you for evaluating the v1.2 CTP and providing feedback.

As Jaaved said earlier, a bug was filed to address this issue. It has since been fixed in internal builds. The next public CTP of the driver, targeted for release later this summer, should contain the fix.

--David Olix [MSFT]

|||

I'm getting the same problem but directly from SQL Server 2005 (SP2)...

In Mangement Studio I'm connected to 'Database_A'

I execute the following SQL:

exec sp_columns
'ViewName'
, 'dbo'
, 'Database_B'

SQL Server returns:

Msg 15250, Level 16, State 1, Procedure sp_columns, Line 24
The database name component of the object qualifier must be the name of the current database.

What the point in providing a database parameter to choose a database if it can only be set to the current database of the connection?

My version is:

Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86) Apr 14 2006 01:12:25 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 1)

|||

I eneded up doing the following as a work around:

exec [Database_B].dbo.sp_columns

'ViewName'

but this isn't ideal as "Database_B" is provided as a parameter to the stored procedure that's executing this code so I have to build some dynamic sql on the fly to execute the statement.

I have no problems with sp_columns_ex when using linked servers so it seems crazy to me that sp_columns doesn't work in the same manner when not linking servers (e.g. "Database_A" and "Database_B" are on the same server)

DatabaseMetadata methods with catalog parameters now error if current database does not match.

In the v1.2 CTP version, the DatabaseMetadata methods for getting information about objects in a database (i.e. getTables(), getColumns(), ...) errors if your current database connection is in a different database than the object you are quering.

Is this the intended behavior going forward?

In my case I have access to both database A and database B. My current connection is in database A , but I am looking up object in database B.

ResultSet rs = conn.getDatabaseMetadata.getTables("B","dbo","%",{"TABLES" });

[junit] The database name component of the object qualifier must be the name of the current database.
[junit] com.microsoft.sqlserver.jdbc.SQLServerException: The database name component of the object qualifier must be the name of
the current database.
[junit] at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.TDSCommand.execute(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeQueryInternal(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getResultSet(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getResultSet(Unknown Source)
[junit] at com.microsoft.sqlserver.jdbc.SQLServerDatabaseMetaData.getColumns(Unknown Source)

~Mike Hale

Hi Michael,

Do you have a standalone application that will reproduce this problem? If not, allow me some time to author one and investigate.

Regards,

Jaaved Mohammed

|||

I see that there is a bug filed for this issue via Microsoft Connect:

http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=277128

We will investigate and prioritize accordingly.

|||

I am not sure you can do this. This implying that you can access tables from database B when you are connected to database A.

This would imply that your connection can be re-directed to another database. My understanding of how this works is that a connection is to a single (one and only one) SQL database.

If this is possible then I would also expect to be able to joins across databases, which I believe is not possible.

|||Michael, did MS ever tell you when this would be released? I'm having the same problem and would like to get the fix in.
|||

Hi,

Thank you for evaluating the v1.2 CTP and providing feedback.

As Jaaved said earlier, a bug was filed to address this issue. It has since been fixed in internal builds. The next public CTP of the driver, targeted for release later this summer, should contain the fix.

--David Olix [MSFT]

|||

I'm getting the same problem but directly from SQL Server 2005 (SP2)...

In Mangement Studio I'm connected to 'Database_A'

I execute the following SQL:

exec sp_columns
'ViewName'
, 'dbo'
, 'Database_B'

SQL Server returns:

Msg 15250, Level 16, State 1, Procedure sp_columns, Line 24
The database name component of the object qualifier must be the name of the current database.

What the point in providing a database parameter to choose a database if it can only be set to the current database of the connection?

My version is:

Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86) Apr 14 2006 01:12:25 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 1)

|||

I eneded up doing the following as a work around:

exec [Database_B].dbo.sp_columns

'ViewName'

but this isn't ideal as "Database_B" is provided as a parameter to the stored procedure that's executing this code so I have to build some dynamic sql on the fly to execute the statement.

I have no problems with sp_columns_ex when using linked servers so it seems crazy to me that sp_columns doesn't work in the same manner when not linking servers (e.g. "Database_A" and "Database_B" are on the same server)

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.