There are lots of aggregation functions in the Oracle database with the prefix wm_, such as wm_concat. What does wm mean?
Workspace Manager, which still exists.
The function used to be under the WMSYS schema. You can see it's removal referred to in this support document, where an older version was queried (quoting from the public part):
select * from SYS.DBA_TAB_PRIVS WHERE PRIVILEGE = 'EXECUTE' and OWNER = 'WMSYS';
WM_CONCAT_IMPL
WM_CONCAT
WM$GETDBVERSIONSTR
WM$DISALLOWQNDML
WM$CONVERTDBVERSION
OWM_9IP_PKG
Of course, it was never officially supported and shouldn't have been used other than by internal Oracle tools, and it not longer exists.
Related
We are migrating our codebase from Delphi XE3 with FireDAC 8.0.5 to Delphi Berlin 10.1 Upd 2 with FireDAC 15.0.1 (Build 86746). Everything is working smoothly using MS Sql Server, but using ORACLE it has been another history.
Throughout the application source code we use lots of TAdQuery with sql instructions like
AdQuery1.Sql.Text := 'SELECT FIELD1, FIELD2 FROM TABLE1';
In order to insert a record, we use Append or Insert methods, like this
AdQuery1.Insert;
//or
AdQuery1.Append;
Just after invoking its Post method, the component internally creates an INSERT sql statement, that goes like this
INSERT INTO TABLE1 (FIELD1, FIELD2) VALUES(:FIELD1, :FIELD2)
So the record gets inserted successfully.
Now, using TFdQuery in Delphi Berlin, the component internally creates an INSERT sql statement, like this
INSERT INTO USERNAME.TABLE1 (FIELD1, FIELD2) VALUES(:FIELD1, :FIELD2)
Failing with a [FireDAC][Phys][Ora] ORA-00942: table or view does not exist
This happens because in our Oracle database, TABLE1 is created in a schema called MAIN_SCHEMA, and we access it by using a public synonym.
Trying to find a workaround, we compared FireDAC source code, finding that
in Delphi XE3, the unit uADDAptManager.pas, on its function TADDAptTableAdapter.GetUpdateRowCommand, calls oConn.CreateCommandGenerator(oCmdGen, nil);
in Delphi Berlin, the unit FireDAC.DApt.pas, on its function TFDDAptTableAdapter.GetUpdateRowCommand
calls oConn.CreateCommandGenerator(oCmdGen, GetSelectCommand);
Whenever that second parameter (called ACommand: IFDPhysCommand) is not nil, the name of the table is returned concatenating the user name (in a function called TFDPhysCommandGenerator.GetFrom).
If we add 'MetaCurSchema=MAIN_SCHEMA' to the TFdConnection params, it works with the applications that not use a pooled connection, but We have several process that use a pooled connection with the same params, even MetaCurSchema param, but it doesn't work
What can we do?
thanks for your help
What I understand is that you would do better making the connection avoid the use of any schema name, rather than specifying it. Also, keeping in mind that you already use public synonyms.
So, according to the documentation:
Full object names
FireDAC supports full object names, which include the catalog and/or schema names.
When a short object name is specified to StoredProcName, TableName, etc, they will be expanded into the full object names, using the current catalog and/or schema names. To override or avoid usage of the current catalog and/or schema names, use the MetaCurCatalog and MetaCurSchema connection definition parameters. For example:
[Oracle_Demo]
DriverID=Ora
...
MetaCurCatalog=*
MetaCurSchema=*
~ Source: Object Names (FireDAC) - docWiki
MetaCurSchema
Specifies the current schema for the application. If not specified, then its value will be received from the DBMS. When an application is asking for metadata and do not specify a schema name, then FireDAC will implicitly use the current schema.
If MetaCurSchema is '*', then schema names will be me omitted from the metadata parameters.
~ Source: Common Connection Parameters (FireDAC) - docWiki
That asterisk (*) should do the trick, let us know if that's the case.
I'm trying to find all (available) SQL history by user in our Oracle 11g database. I've tried using some view such as v$sql_monitor, v$sqlarea, and dba_hist_active_sess_history to try to get usernames, and their executed SQL statements (joined on SID and Serial #) but I'm not having any luck. Our senior DBA and DBE said they've done it before but just told me to look in sqlarea since that has the longest history of SQL held. I'm not having any luck with this. Is this possible to do in Oracle?
Edit: We use SQL Developer. I understand that TOAD may or may not have this feature built-in but I haven't been able to find anything that accomplishes this (other than view current sessions and current SQL) in SQL Developer.
You can try something like that if you have the proper licensing to query dba_hist_active_sess_history, you need a license for the diagnostic pack:
select trunc(hist.sample_time,'DD'),u.name,hist.sql_id,sql.sql_text
from dba_hist_active_sess_history hist,
dba_hist_sqltext sql,
user$ u
where hist.sql_id = sql.sql_id
and hist.user_id = u.user#;
I think the only way to fetch the exact SQL-Executions of a User (i think you mean Session?) is by enabeling Tracing.
I think this article (https://oracle-base.com/articles/misc/sql-trace-10046-trcsess-and-tkprof) gives you a good instruction how it is used.
I'm trying to get SAP Business Objects to get a report off of a stored procedure. I had no luck, so I'm now just trying with an example/tutorial of how to do it I found online, and I can't get that to work either.
I'm following:
https://irfansworld.wordpress.com/2012/11/17/what-you-should-know-about-stored-procedure-universe-in-bi-4-0/
I created the objects shown in the exact same way, as shown here:
create or replace package emp_package
as type emp_row_type is ref cursor return emp%rowtype;
end emp_package;
/
create or replace
procedure getEmployeesByDepartment
(
return_rows_cursor in out emp_package.emp_row_type,
dept_parameter in emp.deptno%type
)
as begin
open return_rows_cursor for
SELECT *
FROM emp
WHERE emp.deptno = dept_parameter;
end;
/
I get good results back:
Package EMP_PACKAGE compiled
Procedure GETEMPLOYEESBYDEPARTMENT compiled
But here is where I see a glaring difference... For me, it takes what should only be the out/return parameters, and prompts me as if they are input parameters.
Even if i say "OK" to this... it doesn't recognize the fields in the "out" cursor as fields for me to show on the report.
I've even tried changing the cursor paramater from "in out" to just "out"... but still no luck.
Any ideas as to why I can't make this example work for me?
Using SAP Universal Design Tool 4.1.
Oracle 11g
This isn't really an answer, but too long for a comment.
I just tried this with BI4.1 SP Patch 5, and the SP Editor displayed as expected (only showing the DEPT_PARAMETER parameter).
Two possibilities I can think of for the different behavior you're seeing:
One is that there's something going on with the database middleware client that's confusing BO about the parameters. I'm using Oracle 11g client, and an Oracle Native connection in BO (i.e., not ODBC or JDBC). If you're using an ODBC or JDBC connection, try the native client instead.
It might be a bug with the specific version of UDT that you're using. I'd suggest upgrading, or contacting SAP support to see if it's a known issue.
I have the linked server set up in SQL Server 2008. But I could not run any query against the linked server.
I tried to run this simple command but it's not working
SELECT * FROM MYSERVER..ALANH.TEMP_UPDATE1
This is the error I got when I run the above command.
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "OraOLEDB.Oracle" for linked server "MYSERVER" reported an error. The provider did not give any information about the error.
Msg 7312, Level 16, State 1, Line 1
Invalid use of schema or catalog for OLE DB provider "OraOLEDB.Oracle" for linked server "MYSERVER". A four-part name was supplied, but the provider does not expose the necessary interfaces to use a catalog or schema.
Could anyone help me to connect to the OracleLinkedServer? Thanks very much.
you can be that way too:
**SELECT * FROM OPENQUERY(MYSERVER, 'SELECT * FROM ALANH.TEMP_UPDATE1')**
You can write the query like this:
select * FROM [MYSERVER]..[ALANH].[TEMP_UPDATE1]
Important: In this case, the fully qualified table name must be written in upper case.
You might try the fix from this article.
Also, this could be a problem with naming. From an MS KB article
If you receive these error messages, a table may be missing in the
Oracle schema or you may not have permissions on that table. Verify
that the schema name has been typed by using uppercase. The
alphabetical case of the table and of the columns should be as
specified in the Oracle system tables.
On the Oracle side, a table or a column that is created without double
quotation marks is stored in uppercase. If the table or the column is
enclosed in double quotation marks, the table or the column is stored
as is.
First make sure the tnsping utility works from client server, then use the below string in linked server database source setup
host[:port]/service_name
Check this link for more details :
http://www.oracledistilled.com/oracle-database/oracle-net/using-easy-connect-ezconnect-naming-method-to-connect-to-oracle-databases/
Try something like this:
SELECT * FROM ALL_TABLES#"SOME.SERVER.NAME";
In this case I'm selecting ALL_TABLES from a linked server called SOME.SERVER.NAME.
Richard's post above was critical.
I am using v12 ODP.NET odbc drivers and had to ensure that "Zero Level Only" was NOT checked and that the names supplied for table and schema were the correct case. All of the schemas and tables I access are uppercase only.
Use the query below to determine what the correct table name is, though you will have to supply the schema name in the correct case for the query to work. Try all uppercase, try all lowercase, try mixed case, or better yet get the actual name from the dba (I've heard that only table/schema names that are "" quoted will be allowed mixed case, otherwise in oracle it's all uppercase.)
sp_tables_ex #table_server=InsertLinkedServerHere, #table_schema=InsertSchemaNameHere
I've researched here and elsewhere but haven't found an answer for the following.
I'd like to get a list of all procedures available to my application's Oracle account (AFAIK they're part of one package), and have tried the following command in sqlplus:
SELECT * from user_procedures;
However this only returns one row/procedure, when in fact the app has probably 20+ procedures it calls (successfully) on a regular basis. I can just look through the source code and extract all the stored procedure names, but I'd like to use the above and see it working, and as a basis for further examination of the db to assist in debugging (instead of always needing to run the app or write test client code, for example).
Does the above statement only return procedures my account owns explicitly, or should it show anything the account has access to? [I'm not very familiar with Oracle's specific features.]
I've tried other variations; for example, referencing 'dba_procedures' results in a 'table or view does not exist error.'
Are all of these symptoms the result of limited permissions on my app's Oracle account (which I'm using to connect via sqlplus)?
[Background: Dysfunctional environment--direct access to the DBMS and its external owners is extremely limited, so I'd like to be able to increase my understanding of the db design and get the information I need without assistance.]
You can see which stand-alone procedure you can execute with this:
select ao.object_type, ao.owner ||'.'|| ao.object_name
from all_objects ao, user_tab_privs utp
where ao.object_type = 'PROCEDURE'
and utp.owner = ao.owner
and utp.table_name = ao.object_name
and utp.privilege = 'EXECUTE';
But if they are in a package you can't directly see the procedure names, AFAIK, but you can see which package you can execute with this:
select ao.object_type, ao.owner ||'.'|| ao.object_name
from all_objects ao, user_tab_privs utp
where ao.object_type = 'PACKAGE'
and utp.owner = ao.owner
and utp.table_name = ao.object_name
and utp.privilege = 'EXECUTE';
And then you can desc[ribe] the package to see the individual procedures and functions within it. I guess that is probably held somewhere in the data dictionary but don't knwo where off-hand...
user_procedures is a system view that holds all the procedures owned by certain schema (user). Not the ones that the schema (user) is granted to execute.
You can try DBMS_METADATA.GET_GRANTED_DDL stored procedure. You might find something useful there. But I don't know what kind of privileges you need to run it within your application.
Hope it helps.
If the procedures are part of a package (i.e. you're calling them by PACKNAME.PROCNAME, then you have an all-or-nothing grant on the package, not individual procedures within the package.