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)]Driver not capable.]
What to do ? What to do ??Well , this Error belongs to Distributed Queries Error Messages collection.
- Remote OLE DB Data Source : ODBC Data Source
- OLE DB Provider : Microsoft OLE DB Provider for ODBC
- Provider Name : MSDASQL
The problem you are getting with only receiving one row on a select statement can be fixed by going into the configuration of the Client Access DSN and go to the other tab and check always scrollable, this will get all the rows.
As far as the other issue getting the error
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)]Driver not capable.]
You get this when journaling is not turned on the table on the AS400. Have one of your AS400 people turn journaling on for all the tables you need to access.
Since you noted that ..." [IBM][Client Access Express ODBC Driver (32-bit)]Driver not capable.] ".... I just could compare this error with one more familiar to Microsoft platform, and what are the reasons for getting this Error when trying to connect to MS Access DB.
1. MS Access DB is not secured Db , and there is no login : Admin with No Password .
2. The Access database is secured and :HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\Sys temDB registry key is not pointing to the correct Access workgroup file.
-If you are trying to Change Data , try without : BEGIN >> COMMIT block, if possible.
-also try this link :
http://www.iseries.ibm.com/developer/db2/documents/mts/mts5.html
Hope this is something to start solving your problem.
rgds.
srdjan|||I linked two MSSQL 2000 servers by using enterprise manager. I succeeded in connecting between server 1(local) and server2 (remote). I have another remote one--server3. I used the same method to try connecting either local and server3, or server2 and server3.
I can do on local and server2 to see data from server3--
select * from server3.pubs.dbo.authors
however if I try to do this on server3
select * from server2.pubs.dbo.authors
I got following error messages:
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'SQLOLEDB' reported an error. The provider did not give any information about the error.
So what is the problem here?
I will appreciate greatly for your help.
Cathy|||1. Check list of Linked Servers in SYSSERVERS system table ( you should have both (Server2 and Server3 ) servers listed .
2. Verify that there is a login mapping for the current user on Server3.
3. Check the rights of user you are trying to connect from your Server to Server3 . ( at least you must SELECT rights on table you are querying) ....
--Returns the list of linked servers defined in the local server
exec sp_linkedservers
--Creates a linked server
exec sp_addlinkedserver
hope this help
rgds.
srdjan|||Thanks for reply.
I checked all . I also used
CREATE Database NorthwindnDistributed
Go
Use NorthwindnDistributed
CREATE TABLE dbo.Customers
(CustomerID char(5),
CompanyName nvarchar(40))
EXEC sp_addlinkedserver @.server = 'remoteserver',
@.srvproduct ='SQLServer OLEDB Provider',
@.provider ='SQLOLEDB',
@.datasrc = 'remote server IPaddress'
IF not Exists (select 'True' From master.dbo.syslogins where Name = 'remoteUser')
EXEC sp_addlogin 'remoteUser','remotePassword'
Use NorthwindnDistributed
exec sp_adduser 'remoteUser'
exec sp_addrolemember 'db_owner', 'remoteUser'
exec sp_addlinkedsrvlogin @.rmtsrvname = GM,
@.useself = FALSE,
@.rmtuser = 'remoteUser',
@.rmtpassword ='remotePassword'
exec sp_serveroption @.server = GM,
@.OPTNAME ='lazy schema validation',
@.OPTVALUE = 'TRUE'
to create new linked servers from both of local and remote sides. It still give me the error message like
Server: Msg 7399, Level 16, State 1, Line 1
OLE DB provider 'SQLOLEDB' reported an error. The provider did not give any information about the error.
I can do "select ..." from one side of server. But when I changed to other servers, I don't have any problems to connect them and work on them. If there is anything wrong when this server is set up? Why can I not get any error messages when i do the same operation on other servers but only fail on one particular server?:confused:
Thanks for any reply.
HELP!
Showing posts with label level. Show all posts
Showing posts with label level. Show all posts
Monday, March 26, 2012
Monday, March 12, 2012
Limiting User Resources
I need to find a way to limit the resources that a user can hog on a SQL mac
hine. Is there any way to do this? I know that you can set priority level
to the SQL process, but we are actually wanting to limit a single user that
does mass updates periodica
lly throughout the day so that other users still get decent, if not stellar,
performance. Any ideas?
Thanks,
JoshJosh,
No, you can not throttle a user.
Perform the updates in smaller chucks by using SET ROWCOUNT and performing t
he update in a loop. Do not forget to use a unique where clause so that it s
kips the rows that were already updated in the next iteration.
Here is one article of many out on the web...
http://www.tek-tips.com/gfaqs.cfm/l...id/183/fid/3141
Norman
Norman
hine. Is there any way to do this? I know that you can set priority level
to the SQL process, but we are actually wanting to limit a single user that
does mass updates periodica
lly throughout the day so that other users still get decent, if not stellar,
performance. Any ideas?
Thanks,
JoshJosh,
No, you can not throttle a user.
Perform the updates in smaller chucks by using SET ROWCOUNT and performing t
he update in a loop. Do not forget to use a unique where clause so that it s
kips the rows that were already updated in the next iteration.
Here is one article of many out on the web...
http://www.tek-tips.com/gfaqs.cfm/l...id/183/fid/3141
Norman
Norman
Wednesday, March 7, 2012
Limitations of compatibility level SQL Server 2000 (80) under SQL
My org has a new SQL Server 2005 server and we've just installed a new
commercial database. After the consultant installed the db, I had a
good look around and realised it's set to a lower compatibility level.
The company that sourced the database assures us that it's 'fully
supported within a SQL Server 2005 environment'.
I trust that the application itself works fine as configured, but am
worried that we'll run into issues when we want to configure Reporting
Services and log shipping later in the year. I've done a bit of
research and it seems we won't have access to 'new' SS2005 features,
such as the database diagram tool and the new TABLESAMPLE clause, and
that the server will parse T-SQL differently depending on what
compatability level the database is set to. But I've yet to find how
(whether) this will affect things log shipping and Reporting Services.
Can anyone shed some light on this for me? I'd want this noted as
outstanding issue that they need to sort (our request for tender docs
specified SQL Server 2005 compatibility), but they seem to think it
meets this requirement even though it's running at a lower
compatibility level. I'd like to have some examples of SQL Server 2005
functions that we won't be able to use because of this.
Much appreciated.Yes - there are some features that will not work in compatibility mode.
Many of the neat performance reports in SSMS are not able to collect data on
databases in earlier compatibility mode. Compatibility mode is geared
towards syntax compatiblity and not as much about behavior compatibility.
This is because fundamentally, the engine has changed and will not emulate
the exact same behavior.
I do not recall seeing a link about all of the features that are affected by
this, but since compatibility mode is a database-level setting, you can
create a dummy DB at the desired db compat level and test it out.
Hope this helps!
Rick Heiges
SQL Server MVP
"RJGiskard" <rjgiskard@.googlemail.com> wrote in message
news:cd79f4ec-3464-41ee-ab75-a9450f8a735f@.d21g2000prf.googlegroups.com...
> My org has a new SQL Server 2005 server and we've just installed a new
> commercial database. After the consultant installed the db, I had a
> good look around and realised it's set to a lower compatibility level.
> The company that sourced the database assures us that it's 'fully
> supported within a SQL Server 2005 environment'.
> I trust that the application itself works fine as configured, but am
> worried that we'll run into issues when we want to configure Reporting
> Services and log shipping later in the year. I've done a bit of
> research and it seems we won't have access to 'new' SS2005 features,
> such as the database diagram tool and the new TABLESAMPLE clause, and
> that the server will parse T-SQL differently depending on what
> compatability level the database is set to. But I've yet to find how
> (whether) this will affect things log shipping and Reporting Services.
> Can anyone shed some light on this for me? I'd want this noted as
> outstanding issue that they need to sort (our request for tender docs
> specified SQL Server 2005 compatibility), but they seem to think it
> meets this requirement even though it's running at a lower
> compatibility level. I'd like to have some examples of SQL Server 2005
> functions that we won't be able to use because of this.
> Much appreciated.
commercial database. After the consultant installed the db, I had a
good look around and realised it's set to a lower compatibility level.
The company that sourced the database assures us that it's 'fully
supported within a SQL Server 2005 environment'.
I trust that the application itself works fine as configured, but am
worried that we'll run into issues when we want to configure Reporting
Services and log shipping later in the year. I've done a bit of
research and it seems we won't have access to 'new' SS2005 features,
such as the database diagram tool and the new TABLESAMPLE clause, and
that the server will parse T-SQL differently depending on what
compatability level the database is set to. But I've yet to find how
(whether) this will affect things log shipping and Reporting Services.
Can anyone shed some light on this for me? I'd want this noted as
outstanding issue that they need to sort (our request for tender docs
specified SQL Server 2005 compatibility), but they seem to think it
meets this requirement even though it's running at a lower
compatibility level. I'd like to have some examples of SQL Server 2005
functions that we won't be able to use because of this.
Much appreciated.Yes - there are some features that will not work in compatibility mode.
Many of the neat performance reports in SSMS are not able to collect data on
databases in earlier compatibility mode. Compatibility mode is geared
towards syntax compatiblity and not as much about behavior compatibility.
This is because fundamentally, the engine has changed and will not emulate
the exact same behavior.
I do not recall seeing a link about all of the features that are affected by
this, but since compatibility mode is a database-level setting, you can
create a dummy DB at the desired db compat level and test it out.
Hope this helps!
Rick Heiges
SQL Server MVP
"RJGiskard" <rjgiskard@.googlemail.com> wrote in message
news:cd79f4ec-3464-41ee-ab75-a9450f8a735f@.d21g2000prf.googlegroups.com...
> My org has a new SQL Server 2005 server and we've just installed a new
> commercial database. After the consultant installed the db, I had a
> good look around and realised it's set to a lower compatibility level.
> The company that sourced the database assures us that it's 'fully
> supported within a SQL Server 2005 environment'.
> I trust that the application itself works fine as configured, but am
> worried that we'll run into issues when we want to configure Reporting
> Services and log shipping later in the year. I've done a bit of
> research and it seems we won't have access to 'new' SS2005 features,
> such as the database diagram tool and the new TABLESAMPLE clause, and
> that the server will parse T-SQL differently depending on what
> compatability level the database is set to. But I've yet to find how
> (whether) this will affect things log shipping and Reporting Services.
> Can anyone shed some light on this for me? I'd want this noted as
> outstanding issue that they need to sort (our request for tender docs
> specified SQL Server 2005 compatibility), but they seem to think it
> meets this requirement even though it's running at a lower
> compatibility level. I'd like to have some examples of SQL Server 2005
> functions that we won't be able to use because of this.
> Much appreciated.
Labels:
commercial,
compatibility,
consultant,
database,
installed,
level,
limitations,
microsoft,
mysql,
oracle,
org,
server,
sql
Subscribe to:
Posts (Atom)