Is it possible to do
alter session set current_schema=MySchema;
inside a package?
Our asp.net web application call Oracle packages. We'd like to connect to database with an Oracle user that is not the owner of MySchema. For that, we grant execute permissions on Other_User to package MyPackage.
Example:
grant execute on MySchema.MyPackage to Other_User
But when web app connects to Oracle and try to execute the stored procedures of MyPackage, it gets errors because tables don't belong to Other_User.
One way to avoid errors is creating synonyms, but we would prefere to use
alter session set current_schema=MySchema;
if possible, inside the package.
EDIT: When trying to put "alter session" in package:
You cannot use DDL statements (which ALTER SESSION is) directly in PL/SQL.
You need to use an EXECUTE IMMEDIATE:
execute immediate 'alter session set current_schema=MySchema';
Related
I have created checkpoint table ggate for replicat rep1 but still I am getting following error:
2014-09-04 23:38:21 ERROR OGG-00446 Oracle GoldenGate Delivery for
Oracle, REP1.prm: Checkpoint table ggate.checkpoint does not exist.
Please create the table or recreate the REP1 group using the correct
table.
2014-09-04 23:38:21 ERROR OGG-01668 Oracle GoldenGate Delivery for
Oracle, REP1.prm: PROCESS ABENDING.
Can anyone tell me how to resolve it?
In this kind of situations you should:
Have you actually run the ADD CHECKPOINTTABLE? if not run it
Check if the checkpoint table actually exists in the database - if it has been created - try to drop it (DROP CHECKPOINTTABLE) and recreate it (ADD CHECKPOINTTABLE)
Check if the checkpoint parameter is correctly set in the GLOBALS config file
Restart the MGR and Extract/Replicat processes
Verify if the user has access on the database to the checkpoint table (insert, update, delete rights)
If nothing works, run 10046 flag on the target database and check what the GoldenGate Replicat process is executing on the database and when it actually fails (what it wants to do on the database and try to do the same commands by yourself)
This is a simple troubleshooting initiative:
Are you using a traditional non-CDB database or a PDB?
Are you using Classic Architecture or Microservices Architecture? - Different approaches when adding a checkpoint table.
How are you running ADD CHECKPOINTTABLE? From GGSCI/AdminClient or from HTML5 page?
In Classic Architecture, do you have CHECKPOINTTABLE parameter set in GLOBALS? (CHECKPOINTTABLE [container.] owner.table)
Who are you logged into the database as when using DBLOGIN USERIDALIAS?
What replicat are you using? - Classic, Coordinated, Integrated, Parallel?
Check the schema where the table is suppose to be? If not there, you can query the DBA_TABLES view for the name of the checkpoint table and see who owns it.
A lot of times when the checkpint table cannot be created it is due to not updating the GLOBALS file and/or connecting as the correct user to the database.
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 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.
So I have a stored procedure that does the following (modified out the data params):
ALTER TABLE dbo.ReceiptInfo NOCHECK CONSTRAINT Credits_ReceiptInfo_FK1;
UPDATE ReceiptInfo SET CreditAccount=#CreditAccount WHERE CreditAccount=#OriginalAccount;
ALTER TABLE dbo.ReceiptInfo CHECK CONSTRAINT Credits_ReceiptInfo_FK1;
This is all in a stored procedure, which runs perfectly fine when I execute it from management studio but skips the alter constraints when called from ASP.net. I know it's at least executing the stored proc, because I get a message saying the update conflicted with the constraint.
For the record, I know this could all be solved by ON UPDATE CASCADE, but that option was rejected by upper management.
When you use Management Studio to execute a stored procedure, that is done under your account that presumably has admin rights.
When you execute the sp from asp.net, you probably use another account, that is not allowed to do this.
How could I add some items to the tempdb anytime SQL Server starts up?
I'm no expert at this, but our ASP SessionState is stored in the DB and for some reason the tempdb items used for the session state get dropped anytime the server restarts. Not only do I need to recreate the items, but I also have to recreate the User mappings to tempdb. I have a script that does it, but I can't figure out how to run it on SQL startup
-- Use TempDB
use tempdb
go
-- Create Temp tables if they don't exist
IF NOT EXISTS(
SELECT 1 FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='BASE TABLE'
AND TABLE_NAME = 'ASPStateTempSessions')
BEGIN
EXECUTE [ASPState].[dbo].[CreateTempTables]
END
-- If ASPSessionState user isn't mapped to temp db, map it
IF IS_MEMBER('ASPSessionState') IS NULL
create user ASPSessionState from login ASPSessionState
-- Give ASPSessionState user read/write permissions to tempdb
exec sp_addrolemember db_datareader, ASPSessionState
go
exec sp_addrolemember db_datawriter , ASPSessionState
go
Um, if you've used the standard settings to enable ASP.Net session state in tempdb, the system should have generated a stored proc (ASPState_Startup) as follows in the master database. This stored proc is configured to run automatically on SQL Server startup:
USE master
GO
DECLARE #sstype nvarchar(128)
SET #sstype = N'sstype_temp'
IF UPPER(#sstype) = 'SSTYPE_TEMP' BEGIN
DECLARE #cmd nchar(4000)
SET #cmd = N'
/* Create the startup procedure */
CREATE PROCEDURE dbo.ASPState_Startup
AS
EXECUTE ASPState.dbo.CreateTempTables
RETURN 0'
EXEC(#cmd)
EXECUTE sp_procoption #ProcName='dbo.ASPState_Startup', #OptionName='startup', #OptionValue='true'
END
So, the temp tables should be being recreated anyway, unless something has been altered since installing.
If additional permissions are required, I'd look to extending the existing CreateTempTables procedure in ASPState.
If this isn't working correctly, you might try using the aspnet_regsql command (found under %Windir%\Microsoft.Net\Framework\<framework version - to remove then re-add session state support to the server. You'd want to use -ssremove then -ssadd, but I'd suggest passing /? first to see all of the applicable options.