I copied a database from a live MSSQL server to my local one, and was able to log in correctly. I am having a problem however in that when it is time to call a stored procedure the Asp.Net application keeps telling me the SP does not exist, when it clearly does.
I am using windows authentication but on the server I was using credentials, could this be the problem?
Also, all of the SP's have my online username attached to their name, as in username.StoredProcedurenName.
Please help I have been trying to fix this for hours.
I just noticed that when I attempt to run the SP from the SQL Management Studio it works, but it appends the username to the SP such as:
USE [DBNAME]
GO
DECLARE #return_value int
EXEC #return_value = [username].[SPNAME]
SELECT 'Return Value' = #return_value
GO
If I remove the username, it says the same thing (SP not found). How do I get around this?
I suspect you are calling your stored procedure without specifying the schema. When calling a stored procedure (or accessing a table, view, etc) that's not in the default schema that your account is configured for, usually dbo, you need to explicitly include the schema like the sql command below
SqlCommand cmd = new SqlCommand("username.StoredProcedurenName", mySqlConnection);
It's likely what Jason said. The solution has to do with rights and ownership. When you see the SP in the SQL Management Studio, under Programmability->Stored Procedures, your SP should have a prefix like "dbo." or "GateKeeper."
If the SP has "dbo." as the prefix, the user account with which you're connecting to the DB just be part of the database owners (dbo) group, otherwise you won't have access to it. So, you can either add the user to that group, or create the stored procedure ("create procedure spBlahBlah as ..") using the account to plan to run the program under; when you call it you use "exec GateKeeper.spBlahBlah" to stipulate the Schema.StoredProcedureName.
Those are your two choices.
Related
I am trying to determine the application that is using a specific session ID in an Oracle 11g database. I can find the service name of the session id using this query
select SID, SERVICE_NAME
from v$session
where SID = <sessionID here>;
Unfortunately, several applications use this service name to connect to the database. Is there another table/query that I can use to determine which application is using this session ID?
There are other columns in V$SESSION that might be useful, e.g.:
select username, osuser, logon_time, status, program, module, client_identifier, client_info
from gv$session
where sid = <sessionID here>;
However it is up to your application to set or override the last four values.
For example, a session started from SQL*Plus shows program as something like sqlplus#client_host (TNS V1-V3) and module as SQL*Plus. SQL Developer shows both values as that name. A JDBC connection will have something like 'JDBC Thin Client' for both by default, but the application can override those and/or set client_identifier and client_info if it chooses to. As can a Pro*C application, which defaults to both program and module looking something like exe_name#client_host (TNS V1-V3).
As SQL Developer is using JDBC, that is overriding both program and module with it's own value; and SQL*Plus is overriding the default module value.
So if the application using the session ID you're interested in has configured any of those values you should get a pretty good idea of what it is. And if it hasn't then you may still get clues about the kind of application (e.g. JDBC). The osuser might be useful too.
See SYS_CONTEXT and the DBMS_APPLICATION_INFO and DBMS_SESSION packages for more about how an application can set those values.
Do we have any way to specify default schema in cataloged DBs in db2 client in AIX.
The problem is , when it's connecting to DB, it's taking user ID as default schema and that's where it's failing.
We have too many scripts that are doing transactions to DB without specifying schema in their db2 sql statements. So it's not feasible to change scripts at all.
Also we can't create users to match schema.
You can try to type SET SCHEMA=<your schema> ; before executing your queries.
NOTE: Not sure if this work (I am without a DB2 database at the moment, but it seems that work) and depending on your DB2 version.
You can create a stored procedure that just changes the current schema and then set the SP as connect proc. You can test some conditions before make that schema change, for example if the stored procedure is executed from the AIX server directly with a given user.
You configure the database to use this SP each time a connection is established by modifying connect_proc
http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.admin.config.doc/doc/r0057371.html
http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/c0057372.html
You can create alias in the new user schema that points to the tables with the other schema. Refer these links :
http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.sql.ref.doc/doc/r0000910.html
http://bytes.com/topic/db2/answers/181247-do-you-have-always-specify-schema-when-using-db2-clp
I am trying to add an control to my page. I am following the wizard. Step 1, I select my connection string. The connection works, no error messages. Step 2, I choose "Specify a custom SQL statement or stored Procedure" radio button. Step 3, in the "SELECT" tab I click the "Stored Prodedure" radio button, then select the stored procedure I would like to use. I take this as confirmation that the connection string is working. Step 4, I press the "Test Query" button.
A pop up appears with the message "There was an error executing the query. Please check the syntax of the command and if present, the types and values of the parameters and ensure they are correct. Could not find stored procedure .
I've tested the procedure in SSMS, and it works. I took the query string that is in the stored procedure and changed the radio from Step 3 to "SQL Statement" and pasted the string into the box. The statement worked fine.
I also changed the permissions for the login specified in the connection string to the same permissions I have on the server. (Full admin rights!) That did not correct the issue. I only found a few questions in the forums regarding this issue, and they all pointed to permission issues, but I have ruled that out as I set the permissions.
The Wizard can find the procedure when I am walking through the Wizard, but it can't find it when I test.
I hope someone can point me in the right direction... Thanks!
* EDIT *
Just to expand on the #BlackjacketMack's answer:
When I use the wizard to create the SqlDataSource, and select the Stored Procedure from the the list, it appears that VS is defaulting to the dbo schema at runtime, even though it displays all the sprocs in each schema. (I verified this by changing the schema the sproc was on to dbo and testing it. The results were returned with no errors.) Within the wizard, I do not see any options to change the schema. If I click the "SQL Statement" radio button and type EXECUTE [APP001].[MyStoredProcedure], it works perfectly. I did try the GRANT EXECUTE as #otaku recommended, but that did not work. I also changed the default schema for the user specified in the connection string to [APP001] to no avail. So this appears to be an issue when using the dropdowns in the wizard. Manually entering the data so that the schema can be fully qualified did the trick!
Make sure the application that you are running have the appropriate grant execute on the database objects. Sometimes they are tied to a database role such as below where the stored procedure need to have the execute permission:
GRANT EXECUTE ON ][dbo].[MyStoreProc] TO U_ExecuteProcs
Qualify your procedure with the schema If the proc has a schema 'APP001' as you indicated in a comment, make sure the Sql being passed looks something like EXEC APP001.YourStoredProcedureName.
Use a profiler! One great way to approach this problem is run a profiler on your SQL...either the MS Profiler, or we use http://anjlab.com/en/projects/opensource/sqlprofiler which used to be free. Basically, you'll see exactly what SQL your application is sending and who the login they're sending it as.
If you gave yourself admin permissions as you indicated, I wouldn't define too many object specific permissions simply because they tend to go unmaintained.
I think defining the execution context within your stored procedure will resolve the issue , Here is the link:
http://technet.microsoft.com/en-us/library/ms188354.aspx
How to create data base link in oracle 11 g to Access Tables.
You seem to have copied the example in the documentation without really understanding it.
The USING 'local' part of the statement is creating a link to 'the local database', where local is the service name of a database. (The example is a bit confusing, to be fair).
When the link is used it tries to interpret local as a service name, appending the current database's domain, as the docs say:
USING 'connect string'
Specify the service name of a remote database. If you specify only the
database name, then Oracle Database implicitly appends the database
domain to the connect string to create a complete service name.
Therefore, if the database domain of the remote database is different
from that of the current database, then you must specify the complete
service name.
If you're trying to create a link back into the same database - which would be a bit odd but I've seen it done in place of grant access across schemas, and that seems to be what the example is hinting at - then you can replace 'local' in the USING clause with the service name of your current database (e.g. USING 'orcl', or whatever).
You can also use a TNS alias; if your tnsnames.ora has an entry for SOME_DB which points to the SID or service name of another database, you can have USING'some_db'`. You should be able to use any connect string I think; certainly Easy Connect is allowed. There's more in the net services admin guide.
As per this how-to, I've successfully configured IIS on my XP-SP3 dev box for SQL Server 2008 Express to save ASP.NET session state information. I'm just using SQL Server because otherwise on every recompile, I was losing the session state which was obnoxious (having to re-login). But, I'm facing an annoying issue in that every time I restart SQL there's this error, and sometimes one or two other very similar friends:
The SELECT permission was denied on the object 'ASPStateTempSessions',
database 'tempdb', schema 'dbo'.
To fix the error, I just open Management Studio and edit the User Mapping for the login/dbo I'm using on the ASPState db, and re-add tempdb to that user with all but deny permissions. Apparently, once the right permissions are there, ASP.NET is able to automatically create the tables it uses. It just can't run that CreateTempTables sproc until the right security is there.
THE QUESTION...
Is there a way to not have to re-do this on every restart of the SQL Server?
I don't really care right now about keeping the temp data across restarts, but I would like to not have to go through this manual step just to get my web app working on localhost, which uses session state variables throughout. I suppose one could resort to some kind of stored procedure within SQL Server to accomplish the task for this machine when the service starts, to not have to do it manually. I'd accept such an answer as a quick fix. But, I'm also assuming there's a better recommended configuration or something. Not seeing an answer to this on the how-to guide or elsewhere here on StackOverflow.
Both answers seem valid; but with most things Microsoft, its all in the setup...
First uninstall the ASPState database by using the command:
aspnet_regsql –ssremove –E -S .
Note:
-E is to indicate you want to use integrated security connection.
-S informs what SQL server and SQL instance to use, and the "." (dot) specifies default local instance
Then re-install using the command:
aspnet_regsql –ssadd –sstype p –E -S .
Note:
The sstype has three options, t | p | c ... the first "t", tells the installer to host all stored procedures in the ASPState database, and all data in the tempdb. The second option "p" tells the installer to persist data to the ASPState database. The last option "c" allows you to specify a different 'custom' database to persist the session state data.
If you reinstall using the "-sstype p" you then need only to supply datareader/datawriter to the ASPState database for the user that's making the connection (in most cases, the application pool's identity in IIS).
The added benefit of persisting the data is that session state is retained even after a restart of the service. The only drawback is that you need to ensure the agent cleanup job is pruning old sessions regularly (it does this by default, every minute).
Important:
If you are running a cluster, you must persist session data. You're only option is to use sstype 'p' or 'c'.
Hope this sheds light on the issue!
For the record, I did find a way to do this.
The issue is that the tempdb is recreated from the model db each time the service restarts. The gist of the solution is to create a stored procedure that does the job, and then make that procedure run at startup.
Source code (credit to the link above) is as follows:
use master
go
-- remove an old version
drop proc AddAppTempDBOwner
go
-- the sp
create proc AddAppTempDBOwner as
declare #sql varchar(200)
select #sql = 'use tempdb' + char(13) + 'exec sp_addrolemember ''db_owner'', ''app'''
exec (#sql)
go
-- add it to the startup
exec sp_procoption 'AddAppTempDBOwner', 'startup', 'true'
go
Well done for finding the strangest way possible to do this.
The correct answer is as follows:
use master
go
EXEC sp_configure 'Cross DB Ownership Chaining', '1'
go
RECONFIGURE
go
EXEC sp_dboption 'ASPState', 'db chaining', 'true'
go