I was trying to look up the syntax for doing this. I used the following:
alter session set flag10g='TRUE'
I get SQL
Error: ORA-02248: invalid option for ALTER SESSION
This line above worked for other parameters that I set but not this one. I'm guessing it's because it has to do with SDO_GEOMETRY but I haven't found anything to say how to set this parameter.
Is there a way to set this in sqldeveloper?
As far as I know flag10g is a parameter of SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT function or SDO_GEOM.VALIDATE_LAYER_WITH_CONTEXT procedure.
See at Spatial and Graph Developer's Guide for details.
Related
apparently there are many ora-00904 errors out there, but I can't find similar case with mine.
my case is related to ref() function in oracle: https://docs.oracle.com/cloud/latest/db112/SQLRF/functions145.htm#SQLRF00694
according to the example in the link above, you can query like below without problem:
select ref(x) from some_table x
but what I get is error ora-00904 invalid column name and it highlighted the x in ref(x)
I can't remove the ref() function from my query as it is added automatically by oracle forms.
Anyone have similar experience? is there some settings to set?
BTW, I am using an ancient oracle form 6i on top of oracle 8i
The ref() function is used in conjunction with user defined types; hence the table alias used by the function needs to refer to a table of a user defined type.
I am a developer with SQL Server experience. We have one legacy application which uses SQR and Oracle to perform a weekly duplicate record search. We got an error while performing this search after 14 years. It says 'ORA-01438: value larger than specified precision allows for this column'. When I googled that error, I found out that it is related to a numeric field and the value passed is larger than it can hold. I can increase the size but don't know for which one. Since no one supports Oracle here, I am trying to trouble shoot this error and found people using
alter system set events='1438 trace name Errorstack forever,level 10';
I would like to know if this is the right way to find out which sql is failing?
Also what does it alter and what is level 10? Anything that I should consider before running this query in production? Is there something I need to roll back after performing this query? I was told that if I do SQL> insert into test values (100000000000000000,'test','test'); where 10000000000000000 is invalid then it will throw generic Oracle message ORA-01438. But in the trace file, it would show ORA-01438: value larger than specified precision allowed for this column. So, where would the trace file be generated?
Current SQL statement for this session:
insert into test values (100000000000000000,'test','test').
Please let me know if I am not in the right path.
Use DBMS_MONITOR to enabling trace for the session affected. This will contain all SQL and errors and bind variables, if you enable it.
I'm trying to convert some Informix ESQL to Oracle Pro*C. In the existing Informix code the "SERIAL" data type was used to indicate automatically incrementing columns. According to the Oracle documentation, the Oracle Migration Workbench for Informix should be able to handle this, and it explains that it converts the "SERIAL" data type into a "NUMBER" with an associated Oracle sequence and trigger. However, when trying to run the tool it simply replaces the word "SERIAL" with "ERROR(SERIAL)", so I've been trying to manually add in the trigger/sequence.
Their example here: http://docs.oracle.com/html/B16022_01/ch2.htm#sthref112 shows a way that this can be done. The sequence appears to be fairly straight forward, however when trying to create a trigger like so:
CREATE TRIGGER clerk.TR_SEQ_11_1
BEFORE INSERT ON clerk.JOBS FOR EACH ROW
BEGIN
SELECT clerk.SEQ_11_1.nextval INTO :new.JOB_ID FROM dual; END;
The Pro*C preprocessor picks up the "CREATE" keyword here, and decides that I'm not allowed to use the host variable ":new.JOB_ID", because host variables cannot be used in conjunction with "CREATE" statements.
My question is, is there some way to create a trigger that links an Oracle sequence to a particular column without using a host variable to specify the column name? The Oracle documentation seems to indicate that their migration tool should be able to cope, which means there must be some way of doing this. However all the examples of the trigger use that I have found all use the host variable which causes the preprocessor to complain.
Thank you for your time.
(Note: I've used the trigger/sequence/column names from the example in the Oracle documentation in the example above.)
I managed to resolve the issue by using an "EXEC SQL EXECUTE IMMEDIATE" statement.
char sql_buf[4096+1];
snprintf(sql_buf, 4096, <sql>);
EXEC SQL IMMEDIATE :sql_buf;
This bypasses the preprocessor and therefore allows the statement through without complaint.
It is impossible to create a trigger that links an Oracle sequence to a particular column without using a "host variable" to specify the column name. By the way it isn't "host variable" - just reference. The same trigger may fire on update and insert for example, so you have to specify what you are referencing: new or old variables. You can do it in MS-SQL but not in Oracle.
Through Oracle queries is it possible to find out which views/synonyms/tables a stored procedure use?
In PL/SQL Developer if you collapse out a stored procedure it will show "References" which shows all the tables/views/synonyms that the stored procedure uses.
I am trying to implement this functionality into a script which will come in handy.
Wondering if anyone knows a script that will fetch me all the synonyms/views/tables that a stored procedure uses?
The information you are looking for is in the user_dependencies/all_dependencies view.
The answer by #Rene is correct however I believe it needs additional explanation. When selecting from all_dependencies you might run query like one below that should give you all the objects that are referencing your SP.
SELECT *
FROM all_dependencies
WHERE "REFERENCED_NAME" = 'vcustomeraddresses';
You might be surprised when it will come back empty-handed.
This is because oracle is CASE SENSITIVE. What this means is that you have to ether disable case sensitivity (if version of oracle you are using is above 10g r2)
ALTER SESSION SET NLS_COMP=LINGUISTIC;
ALTER SESSION SET NLS_SORT=BINARY_CI;
or upper both sides when comparing
SELECT *
FROM all_dependencies
WHERE upper("REFERENCED_NAME") = upper('vcustomeraddresses');
Hope this saves you some time and frustration.
I have a stored procedure that consists of a single select query used to insert into another table based on some minor math that is done to the arguments in the procedure. Can I generate the plan used for this query by referencing the procedure somehow, or do I have to copy and paste the query and create bind variables for the input parameters?
Use SQL Trace and TKPROF. For example, open SQL*Plus, and then issue the following code:-
alter session set tracefile_identifier = 'something-unique'
alter session set sql_trace = true;
alter session set events '10046 trace name context forever, level 8';
select 'right-before-my-sp' from dual;
exec your_stored_procedure
alter session set sql_trace = false;
Once this has been done, go look in your database's UDUMP directory for a TRC file with "something-unique" in the filename. Format this TRC file with TKPROF, and then open the formatted file and search for the string "right-before-my-sp". The SQL command issued by your stored procedure should be shortly after this section, and immediately under that SQL statement will be the plan for the SQL statement.
Edit: For the purposes of full disclosure, I should thank all those who gave me answers on this thread last week that helped me learn how to do this.
From what I understand, this was done on purpose. The idea is that individual queries within the procedure are considered separately by the optimizer, so EXPLAIN PLAN doesn't make sense against a stored proc, which could contain multiple queries/statements.
The current answer is NO, you can't run it against a proc, and you must run it against the individual statements themselves. Tricky when you have variables and calculations, but that's the way it is.
Many tools, such as Toad or SQL Developer, will prompt you for the bind variable values when you execute an explain plan. You would have to do so manually in SQL*Plus or other tools.
You could also turn on SQL tracing and execute the stored procedure, then retrieve the explain plan from the trace file.
Be careful that you do not just retrieve the explain plan for the SELECT statement. The presence of the INSERT clause can change the optimizer goal from first rows to all rows.