In a software we've acquired, we found that there are some package bodies that have procedures that are just defined as null. For example:
procedure execute_report(parameters) is
begin
null;
end;
Despite this, these procedures are being used through the forms, and they seem to work properly. As in the example, calling the procedure "execute_report" actually runs a report.
The procedure is not defined in any library, or even using the query:
SELECT * FROM ALL_OBJECTS WHERE OBJECT_NAME LIKE '%EXEC%'
does not return anything from the database that might be called...
Is there a way to hide the code in the forms, libraries or DB that I'm missing?
You probably have a pll (forms library) that contains the procedure execute_report
Then this will be called instead of the database version.
Related
Create some package:
create or replace package my_package is
some_var number := 10;
end;
and use it in Sql:
select my_package.some_var from dual
So it gives error PLS-221.
P.S. I know that I can use wrapper function. My question is why this is not allowed. Can anyone point to the documentation where the reason?
I am going to jump and try to answer your question. It is one I heard of sometimes and indeed has been for a while as a Enhancement Request ( Base ER: ENH 6525013 ), as it was very well pointed by #Anum Kumar.
Why is not possible ? Well, I think the Oracle developers of PL/SQL though about Packages merely as collections of logical subprograms and routines. So make available variables directly to external APIs ( OCI or Java ) was never the intention of the concept.
You don't really have a document link telling you that is not possible, as far as I know, but if you read the documentation of the concept itself, you might get some insights:
A package is a schema object that groups logically related PL/SQL types, variables, constants, subprograms, cursors, and exceptions. A package is compiled and stored in the database, where many applications can share its contents. A package always has a specification, which declares the public items that can be referenced from outside the package. In either the package specification or package body, you can map a package subprogram to an external Java or C subprogram by using a call specification, which maps the external subprogram name, parameter types, and return type to their SQL counterparts.
That is the key, you can map any subprogram of a package to any external Java, C routine; but you can't reference a constant variable directly without the corresponding subprogram ( in your case a function ).
However, you can't use it on SQL, but you can in PL/SQL. Keep in mind that Oracle contains different areas in the Library cache to handle SQL and PLSQL. The library cache holds executable forms of PL/SQL programs and Java classes. These items are collectively referred to as program units.
Example
CREATE OR REPLACE PACKAGE pkg IS
n NUMBER := 5;
END pkg;
/
Package created.
SQL> CREATE OR REPLACE PACKAGE sr_pkg IS
PRAGMA SERIALLY_REUSABLE;
n NUMBER := 5;
END sr_pkg;
/
Package created.
SQL> select sr_pkg.n from dual ;
select sr_pkg.n from dual
*
ERROR at line 1:
ORA-06553: PLS-221: 'N' is not a procedure or is undefined
SQL> set serveroutput on
SQL> BEGIN
pkg.n := 10;
sr_pkg.n := 10;
END;
/
PL/SQL procedure successfully completed.
SQL> BEGIN
DBMS_OUTPUT.PUT_LINE('pkg.n: ' || pkg.n);
DBMS_OUTPUT.PUT_LINE('sr_pkg.n: ' || sr_pkg.n);
END;
/
pkg.n: 10
sr_pkg.n: 5
PL/SQL procedure successfully completed.
In the example above, I can't use the SQL engine to reference a constant variable, as I would need a subprogram or routine ( this is an OCI call, but it might very well be a Java program, ProC, etc. I specifically used one of the packages as serially_reusable that you can check how the variable does not change even if I try to.
However, if I don't use the SQL engine, I can use it without any problem within PL/SQL.
I hope it clarifies.
Is it possible to execute a view with a stored procedure?
My procedure should first run the views (I have 2 in total) and then am combining these 2 views data into a different table for applying transformations.
Something like this:
create or replace procedure procname as
begin
here my views should get triggered and then starts my
execute immediate 'truncate table transtable';
insert
...
.....
...
exception
end;
What do you call "execute a view with stored procedure"? How are views "triggered"?
If you meant to ask whether you can create views in a procedure - then yes, you can - using execute immediate. Though, in Oracle, that's highly unusual practice. We create views first (at SQL level), use them everywhere (in SQL or PL/SQL) and that's what I'd suggest you to do.
If you ask why?, reason is simple: dynamic SQL doesn't scale, it is difficult to maintain and debug, and - if there's nothing "dynamic" in it, don't use it.
Moreover, if you reference those views later in your code (and they don't exist at time of compilation), PL/SQL procedure will fail with ORA-00942 (table or view doesn't exist) which means that the rest of your code should also be dynamic.
Nightmare at the horizon, in my opinion.
From what you posted so far, I don't see why would you insist on doing that dynamically:
create view "now" at SQL level
use them in the procedure
I am new at programming with delphi. I am currently creating a simple notebook program and i need some help. I have a form called contacts with 5 tEdit fields. I am thinking i could create a stored procedure in my sybase database to insert record into Contacts table, so I can call it with my delphi programm. How do I call this procedure in delphi? the values that will be inserted should be taken from users input into these tEdit fields. Anyone has any suggestions? Or am I thinking the wrong way? thanks in advance
You have several options here, and it will depend on what VCL controls you are using.
(1). You can insert via a tTable component. This let's you have a quick, easy, low level control. You drop the component on the form, set the component properties (tablename, etc), then something like
MyTable.Open;
MyTable.Insert; (or maybe append)
MyTable.FieldByName('MY_FIELD').AsString := 'Bob'; // set the field values
MyTable.post;
(2). Use SQL. Drop a SQL component on the form. Set the SQLText property, using parameters;
for example : "Insert into table (MyField) values :X". My opinion is that this is easier to do in complex situations, correlated subselects, etc.
MySQL.Close;
MySQL.ParamByName('X').AsString := 'BOB';
ExecSQL;
(3). Use stored procedures. - The advantage to this is that they are useable by multiple applications, and can be changed easily. If you want to update the SQL code, you update it once (in the database), versus having to change it in an app, and then distribute the app to multiple users.
The code for this will be nearly identify to (2), although I don't know the specifics of your VCL library. In effect though, you will specify the routine to run, specify the parameter values, and then execute the stored procedure.
Note that all these routines will return an error code or exception code. It is best practice to always check for that...
Here is a little more complex example, using a SQL statement called qLoader. qLoader exists on a datamodule. I am passing a parameter, executing the SQL statement, then iterating through all the results.
try
with dmXLate.qLoader do
begin
Close;
ParamByName('DBTYPE').AsString := DBType;
Open;
while not dmXLate.qLoader.Eof do
begin
// Here is where we process each result
UserName:= dmXLate.qLoader.FieldByName('USERNAME').AsString;
dmXLate.qLoader.Next;
end;
end;
except
on E: Exception do
begin
ShowMEssage(E.Message);
exit;
end;
end;
When I created my stored procedure somehow I managed to place it within the stored procedures folder, however not inside the system stored procedures folder (the system SP folder exists within the stored procedures folder). How do I move it one level down into the system stored procedures folder?
EDIT: After reading the answers below I'm thinking that the problem is how I'm telling my C# program to access the stored procedure. I have this line of code that is throwing an exception, telling me that it cannot find it:
SqlCommand cmd = new SqlCommand("<database_name>.dbo.<stored_procedure_name>.sql", conn);
If anyone can offer any help on how to call the stored procedure properly it would be appreciated. Thx!
You don't, or at the least shouldn't.
This is for system stored procedures, which are built into the RDBMS and used for system functions, like renaming objects or checking users on the server.
Don't think of these as folders like in a file system - they are just organizing your objects based on existing meta-data (Stored procedure or View? System object or User object?)
You can conceivably mark it as a system object, but that's just a terrible idea.
Why do you want to obfuscate your procedure? If you are creating it it's obviously a user procedure and not a system one.
I'm really not sure why you would need to do this, but you can:
exec sp_ms_marksystemobject myprocname
It's undocumented - so I you won't have any support if you try and use it, and it might be removed from a future version of SQL Server.
+1 for #JNK's comment above.
Also, ensure that you've created the stored procedure under the schema you think you did. If you execute a statement like this:
create procedure foobar as ...
the stored procedure foobar gets created under your default schema, which is likely not dbo. You should always create and reference database objects with at least a 2-level, schema-qualified name:
create procedure dbo.foobar ...
create procedure some_schema.foobar ...
lest you shoot yourself in the foot. You should schema-qualify references as well. References like
select * from some_table
exec some_stored_procedure
rather than
select * from dbo.some_table
exec dbo.some_stored_procedure
are resolved by first probing for an object of the desired name and type under your default schema. If found, that is the object used to resolve the reference. If no such object is found, then a probe is made under the schema dbo.
Further, you should not generally give a stored procedure a name that begins with sp_: that further complicates (and slows down) resolution, throwing probes of the master database into the mix.
I have triggers on a table but I want to invoke them only when the table is altered by an application directly (.NET application) and not if it is altered because of some other stored proc which may be in same database or an another database. Is there anything like ClientID or something which could help me distinguish and invoke trigger conditionally.
Thanks.
The trigger will always be invoked but obviously you can just put conditional logic in to RETURN if you don't want additional code to run.
A couple of functions which might help are APP_NAME() or CONTEXT_INFO()
Failing that you could try
SELECT *
FROM sys.dm_exec_sessions
WHERE session_id = ##SPID
to see if anything suitable is there.
Don't rely on these for security however as they are easily manipulable by the client.