I am having an issue using linked servers on
active/active cluster. I have two instances, and when
both instances are on the same machine, things work as
expected. When I move one of the instances to the other
machine, it does not. It appears to work correctly when I
link the named instance to the default instance. I am
having issues linking the default instance to the named
instance.
What is the text of the query you are issuing? What error is returned from
the Linked Server query? What are the SQL Server and operating system
versions?
Regards,
Farooq Mahmud [MS SQL Support]
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Showing posts with label machine. Show all posts
Showing posts with label machine. Show all posts
Monday, March 19, 2012
Friday, March 9, 2012
server view performance worse than not using view
Consider pseudo-DDL created on an "archive" machine, that wants to get data
from the "live" machine.
CREATE VIEW AllTransactions AS
SELECT * FROM Tranasction_Archived
UNION ALL
SELECT * FROM LinkedServerToLive.Northwind.dbo.Transactions
Now ideally, you can query the Transactions view on the archive machine:
SELECT *
FROM AllTransactions t
INNER JOIN Customers c
ON t.cid = c.cid
and get presented a unified result set. But it turns out this performance is
horrible.
But, if you simply change your query to:
SELECT *
FROM Transactions_Archived t
INNER JOIN Customers c
ON t.cid = c.cid
UNION ALL
SELECT *
FROM LinkedServerToLive.Northwind.dbo.Transactions t
INNER JOIN Customers c
ON t.cid = c.cid
You will get a phenominal performance boost. All i did was break out what
the view contained,
and did the UNION ALL at the query level rather than abstract the complexity
into a view.
i am using SQL2000, is this a known optimizer failing that is fixed in
SQL2005?What are the differences in the execution plans? Are indexes being used to
their full advantage on the joins for both queries?
"Ian Boyd" wrote:
> Consider pseudo-DDL created on an "archive" machine, that wants to get dat
a
> from the "live" machine.
> CREATE VIEW AllTransactions AS
> SELECT * FROM Tranasction_Archived
> UNION ALL
> SELECT * FROM LinkedServerToLive.Northwind.dbo.Transactions
> Now ideally, you can query the Transactions view on the archive machine:
> SELECT *
> FROM AllTransactions t
> INNER JOIN Customers c
> ON t.cid = c.cid
> and get presented a unified result set. But it turns out this performance
is
> horrible.
> But, if you simply change your query to:
> SELECT *
> FROM Transactions_Archived t
> INNER JOIN Customers c
> ON t.cid = c.cid
> UNION ALL
> SELECT *
> FROM LinkedServerToLive.Northwind.dbo.Transactions t
> INNER JOIN Customers c
> ON t.cid = c.cid
> You will get a phenominal performance boost. All i did was break out what
> the view contained,
> and did the UNION ALL at the query level rather than abstract the complexi
ty
> into a view.
> i am using SQL2000, is this a known optimizer failing that is fixed in
> SQL2005?
>
>|||My understanding, from a logical perspective, is this (see disclaimer
below)...
Regardless of your DBMS product, if you are using Oracle DB links or Linked
Servers in SQL Server, or some other artificial method to make DatabaseA
access a table in DatabaseB as if the tables were in the same database, then
the standard tuning mechanisms can no longer be used.
Basically, DatabaseA knows nothign about the tables in DatabaseB, and the
best it can do is link one column in the source database to the result set
in the remote database. IF the remote database has a view, the view cannot
be broken down efficiently into its parts, as it would if the databases were
the same. The remote database ends up processing the entire view in order
to return one row (although it may use an index based on criteria passed).
If the view were in the same database, then the tuning engine would
essentially rewrite the SQL and process the individual joins more
efficiently.
Think of it like going to the library and getting 5 books that you want, as
compared to submitting 5 requests for someone else to get the book, all of
which get handled seperately.
As usual, I am speaking regarding my own limited understanding of the SQL
Server engine. If anyone knows differently, or can explain it better,
please do.
"Ian Boyd" <ian.msnews010@.avatopia.com> wrote in message
news:%23wziZJfIGHA.532@.TK2MSFTNGP15.phx.gbl...
> Consider pseudo-DDL created on an "archive" machine, that wants to get
data
> from the "live" machine.
> CREATE VIEW AllTransactions AS
> SELECT * FROM Tranasction_Archived
> UNION ALL
> SELECT * FROM LinkedServerToLive.Northwind.dbo.Transactions
> Now ideally, you can query the Transactions view on the archive machine:
> SELECT *
> FROM AllTransactions t
> INNER JOIN Customers c
> ON t.cid = c.cid
> and get presented a unified result set. But it turns out this performance
is
> horrible.
> But, if you simply change your query to:
> SELECT *
> FROM Transactions_Archived t
> INNER JOIN Customers c
> ON t.cid = c.cid
> UNION ALL
> SELECT *
> FROM LinkedServerToLive.Northwind.dbo.Transactions t
> INNER JOIN Customers c
> ON t.cid = c.cid
> You will get a phenominal performance boost. All i did was break out what
> the view contained,
> and did the UNION ALL at the query level rather than abstract the
complexity
> into a view.
> i am using SQL2000, is this a known optimizer failing that is fixed in
> SQL2005?
>|||"Mark Williams" <MarkWilliams@.discussions.microsoft.com> wrote in message
news:B88552FB-15AD-443B-ACC9-8A8269741E50@.microsoft.com...
> What are the differences in the execution plans? Are indexes being used to
> their full advantage on the joins for both queries?
It looks as though in the slow case, SQL Server is performing tens of
thounds of executes on a single-row returning query, verses bringing back
tens of thousands of rows.
i would have posted the showplan_text outputs, but it did not show the
number of executes or rows returned through each step.
from the "live" machine.
CREATE VIEW AllTransactions AS
SELECT * FROM Tranasction_Archived
UNION ALL
SELECT * FROM LinkedServerToLive.Northwind.dbo.Transactions
Now ideally, you can query the Transactions view on the archive machine:
SELECT *
FROM AllTransactions t
INNER JOIN Customers c
ON t.cid = c.cid
and get presented a unified result set. But it turns out this performance is
horrible.
But, if you simply change your query to:
SELECT *
FROM Transactions_Archived t
INNER JOIN Customers c
ON t.cid = c.cid
UNION ALL
SELECT *
FROM LinkedServerToLive.Northwind.dbo.Transactions t
INNER JOIN Customers c
ON t.cid = c.cid
You will get a phenominal performance boost. All i did was break out what
the view contained,
and did the UNION ALL at the query level rather than abstract the complexity
into a view.
i am using SQL2000, is this a known optimizer failing that is fixed in
SQL2005?What are the differences in the execution plans? Are indexes being used to
their full advantage on the joins for both queries?
"Ian Boyd" wrote:
> Consider pseudo-DDL created on an "archive" machine, that wants to get dat
a
> from the "live" machine.
> CREATE VIEW AllTransactions AS
> SELECT * FROM Tranasction_Archived
> UNION ALL
> SELECT * FROM LinkedServerToLive.Northwind.dbo.Transactions
> Now ideally, you can query the Transactions view on the archive machine:
> SELECT *
> FROM AllTransactions t
> INNER JOIN Customers c
> ON t.cid = c.cid
> and get presented a unified result set. But it turns out this performance
is
> horrible.
> But, if you simply change your query to:
> SELECT *
> FROM Transactions_Archived t
> INNER JOIN Customers c
> ON t.cid = c.cid
> UNION ALL
> SELECT *
> FROM LinkedServerToLive.Northwind.dbo.Transactions t
> INNER JOIN Customers c
> ON t.cid = c.cid
> You will get a phenominal performance boost. All i did was break out what
> the view contained,
> and did the UNION ALL at the query level rather than abstract the complexi
ty
> into a view.
> i am using SQL2000, is this a known optimizer failing that is fixed in
> SQL2005?
>
>|||My understanding, from a logical perspective, is this (see disclaimer
below)...
Regardless of your DBMS product, if you are using Oracle DB links or Linked
Servers in SQL Server, or some other artificial method to make DatabaseA
access a table in DatabaseB as if the tables were in the same database, then
the standard tuning mechanisms can no longer be used.
Basically, DatabaseA knows nothign about the tables in DatabaseB, and the
best it can do is link one column in the source database to the result set
in the remote database. IF the remote database has a view, the view cannot
be broken down efficiently into its parts, as it would if the databases were
the same. The remote database ends up processing the entire view in order
to return one row (although it may use an index based on criteria passed).
If the view were in the same database, then the tuning engine would
essentially rewrite the SQL and process the individual joins more
efficiently.
Think of it like going to the library and getting 5 books that you want, as
compared to submitting 5 requests for someone else to get the book, all of
which get handled seperately.
As usual, I am speaking regarding my own limited understanding of the SQL
Server engine. If anyone knows differently, or can explain it better,
please do.
"Ian Boyd" <ian.msnews010@.avatopia.com> wrote in message
news:%23wziZJfIGHA.532@.TK2MSFTNGP15.phx.gbl...
> Consider pseudo-DDL created on an "archive" machine, that wants to get
data
> from the "live" machine.
> CREATE VIEW AllTransactions AS
> SELECT * FROM Tranasction_Archived
> UNION ALL
> SELECT * FROM LinkedServerToLive.Northwind.dbo.Transactions
> Now ideally, you can query the Transactions view on the archive machine:
> SELECT *
> FROM AllTransactions t
> INNER JOIN Customers c
> ON t.cid = c.cid
> and get presented a unified result set. But it turns out this performance
is
> horrible.
> But, if you simply change your query to:
> SELECT *
> FROM Transactions_Archived t
> INNER JOIN Customers c
> ON t.cid = c.cid
> UNION ALL
> SELECT *
> FROM LinkedServerToLive.Northwind.dbo.Transactions t
> INNER JOIN Customers c
> ON t.cid = c.cid
> You will get a phenominal performance boost. All i did was break out what
> the view contained,
> and did the UNION ALL at the query level rather than abstract the
complexity
> into a view.
> i am using SQL2000, is this a known optimizer failing that is fixed in
> SQL2005?
>|||"Mark Williams" <MarkWilliams@.discussions.microsoft.com> wrote in message
news:B88552FB-15AD-443B-ACC9-8A8269741E50@.microsoft.com...
> What are the differences in the execution plans? Are indexes being used to
> their full advantage on the joins for both queries?
It looks as though in the slow case, SQL Server is performing tens of
thounds of executes on a single-row returning query, verses bringing back
tens of thousands of rows.
i would have posted the showplan_text outputs, but it did not show the
number of executes or rows returned through each step.
Wednesday, March 7, 2012
server Unable to insert result into a table
I have a 2000 machine which calls a stored procedure on another 2000 machine via a linked server. The results come back and insert into a temporary table.
When I use the same code executing the from the 2000 machine over to 2005 machine via a linked server I cannot insert into the table. But I am able to see the data if I remove the insert statement.
I have tried to place the data into a permanent table without success. I have also checked to be sure the linked server properties are the same.
Any help on this would be appreciated. Below is the code. It is very simple and returns only one value but the bigger procedure that is ran returns several records and mutliple columns. This seems to easy but doesn't work.
DECLARE @.retval AS INT
DECLARE @.value AS INT
SET @.value = 4
CREATE TABLE #TempTable (Value DECIMAL(19, 10) NULL)
INSERT INTO #TempTable
EXEC @.RetVal = Server.Database.dbo.testproc @.value
SELECT * FROM #TempTable
DROP TABLE #TempTable
You need to turn the MSDTC service on.
START > SETTINGS > CONTROL PANEL > ADMINISTRATIVE TOOLS > SERVICES. Find the service called 'Distributed Transaction Coordinator' and RIGHT CLICK (on it and select) > Start.
|||THE MSDTC is already started on both servers. I also tried restarting it on both servers with no luck.|||Do your servers have instance names? If so you would have to add these when you link the servers.eg
Code Snippet
exec sp_addlinkedserver 'ServerName\InstanceName'
Try a simple select from one server to another, this should tell you if it is a linked server problem, or then we know there is something amok in your query.
Post back your findings 
Are you getting an error?
I don't know which OS you're using but this link may be useful...
http://support.microsoft.com/kb/899191
|||That helped at least I can get an error message now instead of query analyzer running forever.
Server: Msg 7390, Level 16, State 2, Line 26
The requested operation could not be performed because OLE DB provider "INSQL" for linked server "INSQL" does not support the required transaction interface.
Friday, February 24, 2012
server to Oracle on Unix
Hi all!
I have a SQL Server from which I need to query a view in a Oracle database.
I have created a linked server connection to the Oracle machine. Oracle,
version 9i, is running on Unix.
Now when I try to use the linked server connection I have some problems.
When I expand the linked server and try to see the tables and views I
sometimes get an error message.
Error 7399: OLE DB provider 'MSDAORA' reported an error.
OLE DB error trace [OLE/DB Provider 'MSDAORA' IDBInitialize::Initialize
returned 0x80004005: ].
Sometimes everything works just fine and sometimes I get the error message
above. When the developers are trying to query the Oracle view they
sometimes get the same error and sometimes the queries works just fine.
The thing is that I don't know anything about Unix so I don't know if there
is something I can do on that side.
Any help or suggestions would be greatly appreciated.A few things you can try:
When the developers are querying Oracle, they can turn on
trace flag 7300 to get a more detailed error message. In
Query Analyzer, execute the following:
Dbcc traceon (7300,3604)
and then try executing the queries against Oracle.
Also, pay attention to the time it takes to execute the
queries when they fail and when they are successful. You
could be experiencing remote query timeouts. You can try
increasing the setting using sp_configure. You can find more
information in books online on using sp_configure.
You will also want to check the following article:
HOW TO: Set Up and Troubleshoot a Linked Server to Oracle in
SQL Server
http://support.microsoft.com/?id=280106
-Sue
On Tue, 16 Nov 2004 12:18:31 +0100, "Jaana"
<jaana.lehtonen@.banverket.se> wrote:
>Hi all!
>I have a SQL Server from which I need to query a view in a Oracle database.
>I have created a linked server connection to the Oracle machine. Oracle,
>version 9i, is running on Unix.
>Now when I try to use the linked server connection I have some problems.
>When I expand the linked server and try to see the tables and views I
>sometimes get an error message.
>Error 7399: OLE DB provider 'MSDAORA' reported an error.
>OLE DB error trace [OLE/DB Provider 'MSDAORA' IDBInitialize::Initialize
>returned 0x80004005: ].
>Sometimes everything works just fine and sometimes I get the error message
>above. When the developers are trying to query the Oracle view they
>sometimes get the same error and sometimes the queries works just fine.
>The thing is that I don't know anything about Unix so I don't know if there
>is something I can do on that side.
>Any help or suggestions would be greatly appreciated.
>
>
I have a SQL Server from which I need to query a view in a Oracle database.
I have created a linked server connection to the Oracle machine. Oracle,
version 9i, is running on Unix.
Now when I try to use the linked server connection I have some problems.
When I expand the linked server and try to see the tables and views I
sometimes get an error message.
Error 7399: OLE DB provider 'MSDAORA' reported an error.
OLE DB error trace [OLE/DB Provider 'MSDAORA' IDBInitialize::Initialize
returned 0x80004005: ].
Sometimes everything works just fine and sometimes I get the error message
above. When the developers are trying to query the Oracle view they
sometimes get the same error and sometimes the queries works just fine.
The thing is that I don't know anything about Unix so I don't know if there
is something I can do on that side.
Any help or suggestions would be greatly appreciated.A few things you can try:
When the developers are querying Oracle, they can turn on
trace flag 7300 to get a more detailed error message. In
Query Analyzer, execute the following:
Dbcc traceon (7300,3604)
and then try executing the queries against Oracle.
Also, pay attention to the time it takes to execute the
queries when they fail and when they are successful. You
could be experiencing remote query timeouts. You can try
increasing the setting using sp_configure. You can find more
information in books online on using sp_configure.
You will also want to check the following article:
HOW TO: Set Up and Troubleshoot a Linked Server to Oracle in
SQL Server
http://support.microsoft.com/?id=280106
-Sue
On Tue, 16 Nov 2004 12:18:31 +0100, "Jaana"
<jaana.lehtonen@.banverket.se> wrote:
>Hi all!
>I have a SQL Server from which I need to query a view in a Oracle database.
>I have created a linked server connection to the Oracle machine. Oracle,
>version 9i, is running on Unix.
>Now when I try to use the linked server connection I have some problems.
>When I expand the linked server and try to see the tables and views I
>sometimes get an error message.
>Error 7399: OLE DB provider 'MSDAORA' reported an error.
>OLE DB error trace [OLE/DB Provider 'MSDAORA' IDBInitialize::Initialize
>returned 0x80004005: ].
>Sometimes everything works just fine and sometimes I get the error message
>above. When the developers are trying to query the Oracle view they
>sometimes get the same error and sometimes the queries works just fine.
>The thing is that I don't know anything about Unix so I don't know if there
>is something I can do on that side.
>Any help or suggestions would be greatly appreciated.
>
>
server to Oracle on Unix
Hi all!
I have a SQL Server from which I need to query a view in a Oracle database.
I have created a linked server connection to the Oracle machine. Oracle,
version 9i, is running on Unix.
Now when I try to use the linked server connection I have some problems.
When I expand the linked server and try to see the tables and views I
sometimes get an error message.
Error 7399: OLE DB provider 'MSDAORA' reported an error.
OLE DB error trace [OLE/DB Provider 'MSDAORA' IDBInitialize::Initialize
returned 0x80004005: ].
Sometimes everything works just fine and sometimes I get the error message
above. When the developers are trying to query the Oracle view they
sometimes get the same error and sometimes the queries works just fine.
The thing is that I don't know anything about Unix so I don't know if there
is something I can do on that side.
Any help or suggestions would be greatly appreciated.
A few things you can try:
When the developers are querying Oracle, they can turn on
trace flag 7300 to get a more detailed error message. In
Query Analyzer, execute the following:
Dbcc traceon (7300,3604)
and then try executing the queries against Oracle.
Also, pay attention to the time it takes to execute the
queries when they fail and when they are successful. You
could be experiencing remote query timeouts. You can try
increasing the setting using sp_configure. You can find more
information in books online on using sp_configure.
You will also want to check the following article:
HOW TO: Set Up and Troubleshoot a Linked Server to Oracle in
SQL Server
http://support.microsoft.com/?id=280106
-Sue
On Tue, 16 Nov 2004 12:18:31 +0100, "Jaana"
<jaana.lehtonen@.banverket.se> wrote:
>Hi all!
>I have a SQL Server from which I need to query a view in a Oracle database.
>I have created a linked server connection to the Oracle machine. Oracle,
>version 9i, is running on Unix.
>Now when I try to use the linked server connection I have some problems.
>When I expand the linked server and try to see the tables and views I
>sometimes get an error message.
>Error 7399: OLE DB provider 'MSDAORA' reported an error.
>OLE DB error trace [OLE/DB Provider 'MSDAORA' IDBInitialize::Initialize
>returned 0x80004005: ].
>Sometimes everything works just fine and sometimes I get the error message
>above. When the developers are trying to query the Oracle view they
>sometimes get the same error and sometimes the queries works just fine.
>The thing is that I don't know anything about Unix so I don't know if there
>is something I can do on that side.
>Any help or suggestions would be greatly appreciated.
>
>
I have a SQL Server from which I need to query a view in a Oracle database.
I have created a linked server connection to the Oracle machine. Oracle,
version 9i, is running on Unix.
Now when I try to use the linked server connection I have some problems.
When I expand the linked server and try to see the tables and views I
sometimes get an error message.
Error 7399: OLE DB provider 'MSDAORA' reported an error.
OLE DB error trace [OLE/DB Provider 'MSDAORA' IDBInitialize::Initialize
returned 0x80004005: ].
Sometimes everything works just fine and sometimes I get the error message
above. When the developers are trying to query the Oracle view they
sometimes get the same error and sometimes the queries works just fine.
The thing is that I don't know anything about Unix so I don't know if there
is something I can do on that side.
Any help or suggestions would be greatly appreciated.
A few things you can try:
When the developers are querying Oracle, they can turn on
trace flag 7300 to get a more detailed error message. In
Query Analyzer, execute the following:
Dbcc traceon (7300,3604)
and then try executing the queries against Oracle.
Also, pay attention to the time it takes to execute the
queries when they fail and when they are successful. You
could be experiencing remote query timeouts. You can try
increasing the setting using sp_configure. You can find more
information in books online on using sp_configure.
You will also want to check the following article:
HOW TO: Set Up and Troubleshoot a Linked Server to Oracle in
SQL Server
http://support.microsoft.com/?id=280106
-Sue
On Tue, 16 Nov 2004 12:18:31 +0100, "Jaana"
<jaana.lehtonen@.banverket.se> wrote:
>Hi all!
>I have a SQL Server from which I need to query a view in a Oracle database.
>I have created a linked server connection to the Oracle machine. Oracle,
>version 9i, is running on Unix.
>Now when I try to use the linked server connection I have some problems.
>When I expand the linked server and try to see the tables and views I
>sometimes get an error message.
>Error 7399: OLE DB provider 'MSDAORA' reported an error.
>OLE DB error trace [OLE/DB Provider 'MSDAORA' IDBInitialize::Initialize
>returned 0x80004005: ].
>Sometimes everything works just fine and sometimes I get the error message
>above. When the developers are trying to query the Oracle view they
>sometimes get the same error and sometimes the queries works just fine.
>The thing is that I don't know anything about Unix so I don't know if there
>is something I can do on that side.
>Any help or suggestions would be greatly appreciated.
>
>
server to ODBC dsn.....
i have a DSN created on the SQL Server machine.
Using my favorite ODBC sql query tool, i can select the System DSN, specify
a login and password, and type a select statement and it all works.
i go into SQL Server, and want to create a linked server to this same ODBC
DSN
Linked server = "BALLYS"
Provider = "Microsoft OLE DB Provider for ODBC Driver"
Data Source="WC400B Bally CMS Testing"
Security-Be made using this security context:
Remote login= [Login Name]
With Password= [Password is blank]
Then i connect to the SQL Server using QA, and try to run my query (that
works in my favorite generic ODBC query tool):
SELECT * FROM OPENQUERY(BALLYS, 'select * from cspcm')
And i get an error message. Now, the error message really shouldn't matter.
My question is, why does it not work? Why didn't Microsoft get ODBC linked
servers right? If any generic stupid 3rd party tool can login and run
queries fine, why can't SQL Server get it right?
But if you care, the error message is:
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]General error.]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]Communication link failure. Comm RC=4 - CWB0999 -
Unexpected error: unexpected return code 4]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize
returned 0x80004005: ].
Now obviously the DB2 ODBC driver works fine, since i can use it fine with
ADO in my own programs, as well as any other program that knows how to use
ODBC.
So why can SQL Server figure out how to use ODBC?
Have you tried with the latest version of Client access express odbc driver from IBM?
What is the level of service pack on SQL?
"Ian Boyd" wrote:
> i have a DSN created on the SQL Server machine.
> Using my favorite ODBC sql query tool, i can select the System DSN, specify
> a login and password, and type a select statement and it all works.
> i go into SQL Server, and want to create a linked server to this same ODBC
> DSN
> Linked server = "BALLYS"
> Provider = "Microsoft OLE DB Provider for ODBC Driver"
> Data Source="WC400B Bally CMS Testing"
> Security-Be made using this security context:
> Remote login= [Login Name]
> With Password= [Password is blank]
> Then i connect to the SQL Server using QA, and try to run my query (that
> works in my favorite generic ODBC query tool):
> SELECT * FROM OPENQUERY(BALLYS, 'select * from cspcm')
> And i get an error message. Now, the error message really shouldn't matter.
> My question is, why does it not work? Why didn't Microsoft get ODBC linked
> servers right? If any generic stupid 3rd party tool can login and run
> queries fine, why can't SQL Server get it right?
> But if you care, the error message is:
> Server: Msg 7399, Level 16, State 1, Line 1
> OLE DB provider 'MSDASQL' reported an error.
> [OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
> (32-bit)][DB2/400 SQL]General error.]
> [OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
> SQLSetConnectAttr failed]
> [OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
> SQLSetConnectAttr failed]
> [OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
> (32-bit)][DB2/400 SQL]Communication link failure. Comm RC=4 - CWB0999 -
> Unexpected error: unexpected return code 4]
> OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize
> returned 0x80004005: ].
>
> Now obviously the DB2 ODBC driver works fine, since i can use it fine with
> ADO in my own programs, as well as any other program that knows how to use
> ODBC.
> So why can SQL Server figure out how to use ODBC?
>
>
Using my favorite ODBC sql query tool, i can select the System DSN, specify
a login and password, and type a select statement and it all works.
i go into SQL Server, and want to create a linked server to this same ODBC
DSN
Linked server = "BALLYS"
Provider = "Microsoft OLE DB Provider for ODBC Driver"
Data Source="WC400B Bally CMS Testing"
Security-Be made using this security context:
Remote login= [Login Name]
With Password= [Password is blank]
Then i connect to the SQL Server using QA, and try to run my query (that
works in my favorite generic ODBC query tool):
SELECT * FROM OPENQUERY(BALLYS, 'select * from cspcm')
And i get an error message. Now, the error message really shouldn't matter.
My question is, why does it not work? Why didn't Microsoft get ODBC linked
servers right? If any generic stupid 3rd party tool can login and run
queries fine, why can't SQL Server get it right?
But if you care, the error message is:
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]General error.]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]Communication link failure. Comm RC=4 - CWB0999 -
Unexpected error: unexpected return code 4]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize
returned 0x80004005: ].
Now obviously the DB2 ODBC driver works fine, since i can use it fine with
ADO in my own programs, as well as any other program that knows how to use
ODBC.
So why can SQL Server figure out how to use ODBC?
Have you tried with the latest version of Client access express odbc driver from IBM?
What is the level of service pack on SQL?
"Ian Boyd" wrote:
> i have a DSN created on the SQL Server machine.
> Using my favorite ODBC sql query tool, i can select the System DSN, specify
> a login and password, and type a select statement and it all works.
> i go into SQL Server, and want to create a linked server to this same ODBC
> DSN
> Linked server = "BALLYS"
> Provider = "Microsoft OLE DB Provider for ODBC Driver"
> Data Source="WC400B Bally CMS Testing"
> Security-Be made using this security context:
> Remote login= [Login Name]
> With Password= [Password is blank]
> Then i connect to the SQL Server using QA, and try to run my query (that
> works in my favorite generic ODBC query tool):
> SELECT * FROM OPENQUERY(BALLYS, 'select * from cspcm')
> And i get an error message. Now, the error message really shouldn't matter.
> My question is, why does it not work? Why didn't Microsoft get ODBC linked
> servers right? If any generic stupid 3rd party tool can login and run
> queries fine, why can't SQL Server get it right?
> But if you care, the error message is:
> Server: Msg 7399, Level 16, State 1, Line 1
> OLE DB provider 'MSDASQL' reported an error.
> [OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
> (32-bit)][DB2/400 SQL]General error.]
> [OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
> SQLSetConnectAttr failed]
> [OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
> SQLSetConnectAttr failed]
> [OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
> (32-bit)][DB2/400 SQL]Communication link failure. Comm RC=4 - CWB0999 -
> Unexpected error: unexpected return code 4]
> OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize
> returned 0x80004005: ].
>
> Now obviously the DB2 ODBC driver works fine, since i can use it fine with
> ADO in my own programs, as well as any other program that knows how to use
> ODBC.
> So why can SQL Server figure out how to use ODBC?
>
>
server to ODBC DSN
i have a DSN created on the SQL Server machine itself. Using my favorite
ODBC sql query tool, i can select the System DSN, specify a login and
password, and type a select statement and it all works. i go into SQL
Server, and want to create a linked server to this same ODBC DSN:
Linked server = "BALLYS"
Provider = "Microsoft OLE DB Provider for ODBC Driver"
Data Source="WC400B Bally CMS Testing"
Security-Be made using this security context:
Remote login= [Login Name]
With Password= [Password is blank]
Then i connect to the SQL Server using QA, and try to run my query (that
works in my favorite generic ODBC query tool):
SELECT * FROM OPENQUERY(BALLYS, 'select * from cspcm')
And i get an error message. Now, the error message really shouldn't matter.
My question is, why does it not work? Why didn't the linked server work? If
any generic 3rd party tool can login and run queries fine, why isn't SQL
Server?
But if you care, the error message is:
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]General error.]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]Communication link failure. Comm RC=4 - CWB0999 -
Unexpected error: unexpected return code 4]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize
returned 0x80004005: ].
Now obviously the DB2 ODBC driver works fine, since i can use it fine with
ADO in my own programs, as well as any other program that knows how to use
ODBC.
So what is SQL Server doing wrong?
Here are all the settings for my linked server setup:
Provider name: Microsoft OLE DB Provider for ODBC Drivers
Product name: [blank]
Data source: WC400B Bally CMS Testing
Provider string: [blank]
Location: [blank]
Catalog: [blank]
Provider Options:
Dynamic parameters: Unchecked
Nested queries: Unchecked
Level zero only: Unchecked
Allow InProcess: Checked
Non transacted updates: Unchecked
Index as access path: Unchecked
Disallow adhoc accesses: Unchecked
Be made using this security contect:
Remote Login: [The login]
With password: [blank - the password is empty]
Server Options:
Collation compatibile: Unchecked
Data Access: Checked
RPC: Unchecked
RPC Out: Unchecked
Use remote connection: Checked
Collation Name: [blank]
Connection Timeout: 0
Query Timeout: 0
Everything is defaulted, aside from the OLEDB Provider Name, the DSN, the
login, and password.
Which of these defaults are wrong, and are preventing SQL Server from
connecting to a remote ODBC data source?
Error when i try various things:
Collation Compatible o o x o x o x o x o x o x o x o x
RPC o o o x x o o x x o o x x o o x x
RPC Out o o o o o x x x x o o o o x x x x
Use Remote Connection o o o o o o o o o x x x x x x x x
Data Access o x x x x x x x x x x x x x x x x
================================================== ==========================
=
Error 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1. Error 7411: Server "BALLYS" is not configured for DATA ACCESS
2. Previous Error
ODBC sql query tool, i can select the System DSN, specify a login and
password, and type a select statement and it all works. i go into SQL
Server, and want to create a linked server to this same ODBC DSN:
Linked server = "BALLYS"
Provider = "Microsoft OLE DB Provider for ODBC Driver"
Data Source="WC400B Bally CMS Testing"
Security-Be made using this security context:
Remote login= [Login Name]
With Password= [Password is blank]
Then i connect to the SQL Server using QA, and try to run my query (that
works in my favorite generic ODBC query tool):
SELECT * FROM OPENQUERY(BALLYS, 'select * from cspcm')
And i get an error message. Now, the error message really shouldn't matter.
My question is, why does it not work? Why didn't the linked server work? If
any generic 3rd party tool can login and run queries fine, why isn't SQL
Server?
But if you care, the error message is:
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]General error.]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]Communication link failure. Comm RC=4 - CWB0999 -
Unexpected error: unexpected return code 4]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize
returned 0x80004005: ].
Now obviously the DB2 ODBC driver works fine, since i can use it fine with
ADO in my own programs, as well as any other program that knows how to use
ODBC.
So what is SQL Server doing wrong?
Here are all the settings for my linked server setup:
Provider name: Microsoft OLE DB Provider for ODBC Drivers
Product name: [blank]
Data source: WC400B Bally CMS Testing
Provider string: [blank]
Location: [blank]
Catalog: [blank]
Provider Options:
Dynamic parameters: Unchecked
Nested queries: Unchecked
Level zero only: Unchecked
Allow InProcess: Checked
Non transacted updates: Unchecked
Index as access path: Unchecked
Disallow adhoc accesses: Unchecked
Be made using this security contect:
Remote Login: [The login]
With password: [blank - the password is empty]
Server Options:
Collation compatibile: Unchecked
Data Access: Checked
RPC: Unchecked
RPC Out: Unchecked
Use remote connection: Checked
Collation Name: [blank]
Connection Timeout: 0
Query Timeout: 0
Everything is defaulted, aside from the OLEDB Provider Name, the DSN, the
login, and password.
Which of these defaults are wrong, and are preventing SQL Server from
connecting to a remote ODBC data source?
Error when i try various things:
Collation Compatible o o x o x o x o x o x o x o x o x
RPC o o o x x o o x x o o x x o o x x
RPC Out o o o o o x x x x o o o o x x x x
Use Remote Connection o o o o o o o o o x x x x x x x x
Data Access o x x x x x x x x x x x x x x x x
================================================== ==========================
=
Error 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1. Error 7411: Server "BALLYS" is not configured for DATA ACCESS
2. Previous Error
server to ODBC DSN
i have a DSN created on the SQL Server machine itself. Using my favorite
ODBC sql query tool, i can select the System DSN, specify a login and
password, and type a select statement and it all works. i go into SQL
Server, and want to create a linked server to this same ODBC DSN:
Linked server = "BALLYS"
Provider = "Microsoft OLE DB Provider for ODBC Driver"
Data Source="WC400B Bally CMS Testing"
Security-Be made using this security context:
Remote login= [Login Name]
With Password= [Password is blank]
Then i connect to the SQL Server using QA, and try to run my query (that
works in my favorite generic ODBC query tool):
SELECT * FROM OPENQUERY(BALLYS, 'select * from cspcm')
And i get an error message. Now, the error message really shouldn't matter.
My question is, why does it not work? Why didn't the linked server work? If
any generic 3rd party tool can login and run queries fine, why isn't SQL
Server?
But if you care, the error message is:
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]General error.]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]Communication link failure. Comm RC=4 - CWB0999 -
Unexpected error: unexpected return code 4]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize
returned 0x80004005: ].
Now obviously the DB2 ODBC driver works fine, since i can use it fine with
ADO in my own programs, as well as any other program that knows how to use
ODBC.
So what is SQL Server doing wrong?
Here are all the settings for my linked server setup:
Provider name: Microsoft OLE DB Provider for ODBC Drivers
Product name: [blank]
Data source: WC400B Bally CMS Testing
Provider string: [blank]
Location: [blank]
Catalog: [blank]
Provider Options:
Dynamic parameters: Unchecked
Nested queries: Unchecked
Level zero only: Unchecked
Allow InProcess: Checked
Non transacted updates: Unchecked
Index as access path: Unchecked
Disallow adhoc accesses: Unchecked
Be made using this security contect:
Remote Login: [The login]
With password: [blank - the password is empty]
Server Options:
Collation compatibile: Unchecked
Data Access: Checked
RPC: Unchecked
RPC Out: Unchecked
Use remote connection: Checked
Collation Name: [blank]
Connection Timeout: 0
Query Timeout: 0
Everything is defaulted, aside from the OLEDB Provider Name, the DSN, the
login, and password.
Which of these defaults are wrong, and are preventing SQL Server from
connecting to a remote ODBC data source?Error when i try various things:
Collation Compatible o o x o x o x o x o x o x o x o x
RPC o o o x x o o x x o o x x o o x x
RPC Out o o o o o x x x x o o o o x x x x
Use Remote Connection o o o o o o o o o x x x x x x x x
Data Access o x x x x x x x x x x x x x x x x
=============================================================================Error 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1. Error 7411: Server "BALLYS" is not configured for DATA ACCESS
2. Previous Error
ODBC sql query tool, i can select the System DSN, specify a login and
password, and type a select statement and it all works. i go into SQL
Server, and want to create a linked server to this same ODBC DSN:
Linked server = "BALLYS"
Provider = "Microsoft OLE DB Provider for ODBC Driver"
Data Source="WC400B Bally CMS Testing"
Security-Be made using this security context:
Remote login= [Login Name]
With Password= [Password is blank]
Then i connect to the SQL Server using QA, and try to run my query (that
works in my favorite generic ODBC query tool):
SELECT * FROM OPENQUERY(BALLYS, 'select * from cspcm')
And i get an error message. Now, the error message really shouldn't matter.
My question is, why does it not work? Why didn't the linked server work? If
any generic 3rd party tool can login and run queries fine, why isn't SQL
Server?
But if you care, the error message is:
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]General error.]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [IBM][Client Access Express ODBC Driver
(32-bit)][DB2/400 SQL]Communication link failure. Comm RC=4 - CWB0999 -
Unexpected error: unexpected return code 4]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize
returned 0x80004005: ].
Now obviously the DB2 ODBC driver works fine, since i can use it fine with
ADO in my own programs, as well as any other program that knows how to use
ODBC.
So what is SQL Server doing wrong?
Here are all the settings for my linked server setup:
Provider name: Microsoft OLE DB Provider for ODBC Drivers
Product name: [blank]
Data source: WC400B Bally CMS Testing
Provider string: [blank]
Location: [blank]
Catalog: [blank]
Provider Options:
Dynamic parameters: Unchecked
Nested queries: Unchecked
Level zero only: Unchecked
Allow InProcess: Checked
Non transacted updates: Unchecked
Index as access path: Unchecked
Disallow adhoc accesses: Unchecked
Be made using this security contect:
Remote Login: [The login]
With password: [blank - the password is empty]
Server Options:
Collation compatibile: Unchecked
Data Access: Checked
RPC: Unchecked
RPC Out: Unchecked
Use remote connection: Checked
Collation Name: [blank]
Connection Timeout: 0
Query Timeout: 0
Everything is defaulted, aside from the OLEDB Provider Name, the DSN, the
login, and password.
Which of these defaults are wrong, and are preventing SQL Server from
connecting to a remote ODBC data source?Error when i try various things:
Collation Compatible o o x o x o x o x o x o x o x o x
RPC o o o x x o o x x o o x x o o x x
RPC Out o o o o o x x x x o o o o x x x x
Use Remote Connection o o o o o o o o o x x x x x x x x
Data Access o x x x x x x x x x x x x x x x x
=============================================================================Error 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1. Error 7411: Server "BALLYS" is not configured for DATA ACCESS
2. Previous Error
server to ODBC DSN
i have a DSN created on the SQL Server machine itself. Using my favorite
ODBC sql query tool, i can select the System DSN, specify a login and
password, and type a select statement and it all works. i go into SQL
Server, and want to create a linked server to this same ODBC DSN:
Linked server = "BALLYS"
Provider = "Microsoft OLE DB Provider for ODBC Driver"
Data Source="WC400B Bally CMS Testing"
Security-Be made using this security context:
Remote login= [Login Name]
With Password= [Password is blank]
Then i connect to the SQL Server using QA, and try to run my query (that
works in my favorite generic ODBC query tool):
SELECT * FROM OPENQUERY(BALLYS, 'select * from cspcm')
And i get an error message. Now, the error message really shouldn't matter.
My question is, why does it not work? Why didn't the linked server work? If
any generic 3rd party tool can login and run queries fine, why isn't SQL
Server?
But if you care, the error message is:
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [IBM][Client Access Express O
DBC Driver
(32-bit)][DB2/400 SQL]General error.]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manag
er] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manag
er] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [IBM][Client Access Express O
DBC Driver
(32-bit)][DB2/400 SQL]Communication link failure. Comm RC=4 - CWB0999 -
Unexpected error: unexpected return code 4]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize
returned 0x80004005: ].
Now obviously the DB2 ODBC driver works fine, since i can use it fine with
ADO in my own programs, as well as any other program that knows how to use
ODBC.
So what is SQL Server doing wrong?
Here are all the settings for my linked server setup:
Provider name: Microsoft OLE DB Provider for ODBC Drivers
Product name: [blank]
Data source: WC400B Bally CMS Testing
Provider string: [blank]
Location: [blank]
Catalog: [blank]
Provider Options:
Dynamic parameters: Unchecked
Nested queries: Unchecked
Level zero only: Unchecked
Allow InProcess: Checked
Non transacted updates: Unchecked
Index as access path: Unchecked
Disallow adhoc accesses: Unchecked
Be made using this security contect:
Remote Login: [The login]
With password: [blank - the password is empty]
Server Options:
Collation compatibile: Unchecked
Data Access: Checked
RPC: Unchecked
RPC Out: Unchecked
Use remote connection: Checked
Collation Name: [blank]
Connection Timeout: 0
Query Timeout: 0
Everything is defaulted, aside from the OLEDB Provider Name, the DSN, the
login, and password.
Which of these defaults are wrong, and are preventing SQL Server from
connecting to a remote ODBC data source?Error when i try various things:
Collation Compatible o o x o x o x o x o x o x o x o x
RPC o o o x x o o x x o o x x o o x x
RPC Out o o o o o x x x x o o o o x x x x
Use Remote Connection o o o o o o o o o x x x x x x x x
Data Access o x x x x x x x x x x x x x x x x
========================================
====================================
=
Error 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1. Error 7411: Server "BALLYS" is not configured for DATA ACCESS
2. Previous Error
ODBC sql query tool, i can select the System DSN, specify a login and
password, and type a select statement and it all works. i go into SQL
Server, and want to create a linked server to this same ODBC DSN:
Linked server = "BALLYS"
Provider = "Microsoft OLE DB Provider for ODBC Driver"
Data Source="WC400B Bally CMS Testing"
Security-Be made using this security context:
Remote login= [Login Name]
With Password= [Password is blank]
Then i connect to the SQL Server using QA, and try to run my query (that
works in my favorite generic ODBC query tool):
SELECT * FROM OPENQUERY(BALLYS, 'select * from cspcm')
And i get an error message. Now, the error message really shouldn't matter.
My question is, why does it not work? Why didn't the linked server work? If
any generic 3rd party tool can login and run queries fine, why isn't SQL
Server?
But if you care, the error message is:
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' reported an error.
[OLE/DB provider returned message: [IBM][Client Access Express O
DBC Driver
(32-bit)][DB2/400 SQL]General error.]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manag
er] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [Microsoft][ODBC Driver Manag
er] Driver's
SQLSetConnectAttr failed]
[OLE/DB provider returned message: [IBM][Client Access Express O
DBC Driver
(32-bit)][DB2/400 SQL]Communication link failure. Comm RC=4 - CWB0999 -
Unexpected error: unexpected return code 4]
OLE DB error trace [OLE/DB Provider 'MSDASQL' IDBInitialize::Initialize
returned 0x80004005: ].
Now obviously the DB2 ODBC driver works fine, since i can use it fine with
ADO in my own programs, as well as any other program that knows how to use
ODBC.
So what is SQL Server doing wrong?
Here are all the settings for my linked server setup:
Provider name: Microsoft OLE DB Provider for ODBC Drivers
Product name: [blank]
Data source: WC400B Bally CMS Testing
Provider string: [blank]
Location: [blank]
Catalog: [blank]
Provider Options:
Dynamic parameters: Unchecked
Nested queries: Unchecked
Level zero only: Unchecked
Allow InProcess: Checked
Non transacted updates: Unchecked
Index as access path: Unchecked
Disallow adhoc accesses: Unchecked
Be made using this security contect:
Remote Login: [The login]
With password: [blank - the password is empty]
Server Options:
Collation compatibile: Unchecked
Data Access: Checked
RPC: Unchecked
RPC Out: Unchecked
Use remote connection: Checked
Collation Name: [blank]
Connection Timeout: 0
Query Timeout: 0
Everything is defaulted, aside from the OLEDB Provider Name, the DSN, the
login, and password.
Which of these defaults are wrong, and are preventing SQL Server from
connecting to a remote ODBC data source?Error when i try various things:
Collation Compatible o o x o x o x o x o x o x o x o x
RPC o o o x x o o x x o o x x o o x x
RPC Out o o o o o x x x x o o o o x x x x
Use Remote Connection o o o o o o o o o x x x x x x x x
Data Access o x x x x x x x x x x x x x x x x
========================================
====================================
=
Error 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1. Error 7411: Server "BALLYS" is not configured for DATA ACCESS
2. Previous Error
Subscribe to:
Posts (Atom)