views:

262

answers:

2

Using the Oracle Data Provider for .NET, my application connects to the database using the privileged SYS user. The connection string is as follows:

Data Source=MyTnsName;User ID=sys;Password=MySysPassword;DBA Privilege=SYSDBA

This works fine with Oracle 10, but Oracle 11 keeps complaining about an invalid username or password. I verified that the password is correct - other apps work fine with the same credentials.

Note that for regular users (without the DBA Privilege part), connecting to Oracle 11 works perfectly.

So, what's wrong?

Update:
This is not an issue with case sensitivity - when constructing the connection string, the password case is not altered by my code, and the password works fine with other, non-.NET-applications.

I suspect that this might be caused by the Oracle 10 client I'm using to connect to the 11 database. Oracle states that the client is upward-compatible, the only drawback being that you cannot use some new features of the database. However, SYSDBA connections clearly are not a new Oracle 11 feature, and - again - a non-.NET-app (Keeptool Hora) can connect using the same setup.

Any other ideas?

Update 2:
The problem persists when using an Oracle 11 client :-(

Update 3:
I made a test with another database installation, version 11.2 (first was 11.1) - same result.

Also, it might be worth noting that with the user SYSTEM (also using the DBA Privilege part), everything works fine. However, I have to work with SYS.

A: 

According to this thread you must add as sysdba to your connectionstring.

klausbyskov
That connection string applies to "Microsoft ODBC for Oracle", I am using "Oracle Data Provider for .NET".
Jens Bannmann
A: 

One thing which changed in 11g is that passwords became case sensitive. I don't know how you're making your ConnectionString, but could it be getting (or putting) the password in the wrong case?

APC
No, that is not the problem here! The connection string is put together with simple concatenation; I checked that there are no case alterations anywhere in my code, and the credentials themselves work in other applications (which are not .NET-based).
Jens Bannmann