Using Oracle SQL Developer I have migrated a very simple SQL Server 2012 database (with only 1 table) to Oracle 12c. Everything went as expected and the report looks as follows.
But when I try to connect the migrated database (Name - DummyDatabase) with username = DummyDatabase and Password = DummyDatabase, I am getting login failure issue as shown below. What might have went wrong?
Finally, I have figured out a fix. The login was failing because the user (i.e., DummyDatabase) itself is not created. This could be because of SQL Developer running generated script (i.e., master.sql) using container DB connection. And Oracle 12c won't allow any user to be created without "c##" prefix in container DB. Hence to fix this I have executed the following command to change the default behavior and then run the generated script in SQL Plus.
alter session set "_ORACLE_SCRIPT"=true;
Related
I have an application which is accessing sql objects(stored procs/tables) etc which are defined under a schema 'A' for example A.my_stored_proc.
This application is working fine as intended when I connect it with the test server database. But, now as the client has asked to copy the db to into a local sql server dev edition for further enhancements.
I took backup of the db from the test server and restored it back to dev system. Now when I change the connection string of the application, the application throws an error saying that unable to located 'A.my_stored_proc'
I decided to manually test all the schema, user roles and rights against the test server which I found all are same.
For testing purpose I renamed the stored proc with 'dbo' schema and the application started working.
Can someone help me with this problem of schema with sql server 2008 r2?
On the test server, the user account under which you application works probably has A as its default schema, yet the procedure is called without schema name mentioned:
exec my_stored_proc;
On the dev server, your user account may have dbo as its default schema (or it might be the owner of the restored database, which in this particular case will lead to the same behaviour).
Consult with SQL Profiler traces to determine how procedure calls look like, exactly.
I have a MVC 4 application using Sql Server 2012 localDB. Inside the application I am using EntityFramework to access data. I have one raw sql command executing as 'select something from [databasename].[dbo].[something]'.
This query works absolutely fine when running through visual studio. But when deployed on IIS 7 for the same query I get an error 'invalid object name'. Rest all queries and EF commands works fine. I realized that this is due to me qualifying the query with database name. But due to some valid reasons, I need to have databasename in this particular query.
Please help!!!
Is the DB you are trying to connect to on the same server? Is it linked? I am thinking not and that is why you need to qualify the query.
If on a different server you need [servername].[databasename].[dbo].[something] and you need to link to the other server.
It was working fine earlier, when I was comparing schema of a database project in Visual studio 2012 with a remote database deployed on a network server, but I am unable to troubleshoot why it is failing now.
It works fine when I compare the schema with same database deployed on local PC. Therefore it seems that comparing tool works, but there seems to be problem with remote server. Any way I can troubleshoot the problem.
The error I am having comparing with remote server is below:
Error 52 Target is unavailable: Value cannot be null.Parameter name: catalogStamp SqlSchemaCompare2 0 0
I came across this same issue recently, probably not the same cause as the original poster but in my case it was down to the compatibility level of the database I was connecting to.
The database I was connecting to was Azure based and Microsoft have recently updated these to default compatibility level 140 (the equivalent of SQL 2017). Previous instances were running on earlier levels and had worked straight from the off, running the below fixed the issue for me:
ALTER DATABASE [Database_Name] SET COMPATIBILITY_LEVEL = 120
Obviously be sure to check any side-effects before you make a compatibility level change on any production db!
As Thibault commented below, if you want to check existing compatibility levels you can use:
SELECT name, compatibility_level FROM sys.databases
And if you want to see what versions the different compatibility levels relate to have a look here https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-compatibility-level
You must specify a login and password when connecting to the SQL server. If you use a login without a password that turns this error.
My DB was Azure SQL DB and was facing this issue, It got resolved for me by using Visual Studio 2017 instead of changing compatibility levels.
Do you have remote access to the SQL DB enabled (is the TCP/IP service enabled) also if you are using SQL Server Login do your SQl Server Security options allow both Windows Authentication and SQL Server Logins ?
I am migrating a classic ASP web app to new servers. The database back end is migrating from SQL Server 2000 to SQL Server 2008, and the app is moving from Win2000 x86 to Win2003R2 x64. I am getting the above error on every single stored procedure call within the application.
I have verified:
Yes, the SQL user is set up, using correct username and password
Yes, the SQL user has execute permissions on the stored procedures in the database
Yes, I have updated the TypeLib references to the new UUID
Yes, I have logged into the database via SSMS with the SQL user id and it can see and execute the stored procedures just fine in SSMS, but not from the web app.
Yes, the SQL user has the database set as its default database.
The most frustrating thing is it works fine on the DEV server, but not on the production server. I have gone through every IIS setting 5 or 6 times and the web app is set up precisely the same in both environments. The only difference is the database server name in the connection string (DEV vs prod)
EDIT: I have also tried pointing the prod web box at the dev database server and get the same error so I'm fairly sure the issue isn't on the database side.
Are you sure that you are really connected to the instance and database you think you are (in the App)? It only takes the wrong DB in the connection string to override the default database for the user.
Can you execute some inline SQL on the connection like:
SELECT ##SERVERNAME AS SERVERNAME
,DB_NAME() AS [DB_NAME]
,CURRENT_USER AS [CURRENT_USER]
It might be the schema. Have you set the default schema of your user in the database you are using?
This wiki post outlines both a problem and a solution. I wanted to post this for others that may be having similar problems, as I couldn't find anything specifically to solve this problem elsewhere.
We recently upgraded our SQL Server 2000 database to SQL Server 2005. One of the databases on the server is a back-end to a MS Access database. The MS Access database uses pass-through queries, via DSN-less ODBC to connect to SQL Server.
An example of the DSN-less connection string is shown below:
ODBC; DRIVER=SQL Server;SERVER=servername;APP=Microsoft® Access (Pass Through
Query);DATABASE=databasename;Network=DBMSSOCN;ConnectionTimeout=20;
Trusted_Connection=Yes
After the upgrade, we found that users were unable to run the pass-through queries, and were getting the following error displayed :
ODBC -- connection to 'SQL Server
' failed
This initially appeared to be a permission issue, as elevating the priveledges of the SQL server logins to sysadmin server role alleviated the problem (but obviously this isn't a great solution).
After taking the logins back out of the sysadmin role we found that when connecting to SQL Server via Management Studio, the login could execute the stored procedures. The very same login could not from within MS Access. This pointed to something MS Access was doing while trying to execute the stored procedures - rather than a permission issue.
We ran a trace on the server using Profiler, and this showed up MS Access trying to execute the following command prior to stored proc execution:
DBCC TRACEON(208)
It appeared to fail at this command, prior to stored procedure execution. Research on the web showed that DBCC TRACEON(208) is equivalent to using 'SET QUOTED IDENTIFIERS ON' command, and that in SQL 2005 priveledges to run this DBCC command had been revoked.
After further research, we found references to MS Query having a similar problem, and that the APP component of the connection string should be changed from 'MS Query' to something else.
On a hunch, we changed our APP component of the ODBC connection string, and MS Access no longer tried executing DBCC TRACEON(208) prior to stored procedure execution.
After further testing, we tracked the problem down to the 'copyright' symbol included in the APP component :
APP=Microsoft® Access (Pass Through Query)
By removing the copyright symbol, all was well with the connection and the application worked as it had previously done on SQL 2000.
Hope this helps out anyone else having a similar problem.
Isn't that the registered trademark symbol?
I believe you hit on one of sql server 2005's defences against odbc based attacks. Since there isn't anything on the internet about it, it is likely something MS handled internally.