example:
create or replace procedure DEMO is
begin
--host dir
--execute immediate 'host dir';
end DEMO;
I pupose invoke window's procedure in Oracle.
I try to use #command in sql*plus, but it discontent my requirement.
Stored procedures run on the database server. SQL*Plus commands are executed on the client. You cannot, therefore, use SQL*Plus commands in a stored procedure.
There is no way realistically for a stored procedure to get a directory listing for a directory on the client machine. (You could, I suppose, have the client expose a shared directory and mount that from the server and the read the contents from the database but that isn't something that would be realistic in the vast, vast majority of cases). A stored procedure can potentially call out to the database server's operating system using a Java or CLR stored procedure or, depending on the version, using the dbms_scheduler package. But there are a lot of security issues to be concerned about before implementing something like this.
Related
we have a package/procedure in a remote database. Say PACKAGE_1.PROCEDURE_1. We want to create a synonym in the local database, that will allow us to still call the package.procedure without coding a DB link in the call. So, to the caller, it looks as though the package.procedure is local to that database.
Can this be done using a synonym?
Sure, you'd just create the synonym
create [public] synonym package_name
for schema_name.package_name#db_link;
Then you'd just call
package_name.procedure_name
in your code and wouldn't need to reference the database link.
I have just started with Basics of PL/SQL and encountered with this statement and I am unable to get this .Please guide .
If I understood what you are saying, then: PL/SQL is executed within the database which is installed on the database server.
Although you can "save" your PL/SQL code into a script which resides on your hard disk (local PC), there's no use of it - it has to be "stored" in the database. That's why we call those procedures "stored procedures". True - there are anonymous PL/SQL blocks, but they also run in the database.
Opposed to those are .SQL scripts, files you can store to your hard disk and execute them "locally" by e.g. connecting to the database via SQL*Plus, a command line tool, and call those locally stored files (if that's what you call "host system").
I was trying to create a procedure within one of the Oracle DBs. Procedure is intended for my colleagues, so that everybody could export the result of the query in a csv-file.
I was using "spool" commands. When running the code between BEGIN and END separately in Oracle SQL Developer (running as script, F5) - it worked, and created the file locally.
Then I tried to put it in the procedure, and that is where issue began. Some compilation errors come out. Most of them have code "PLS-00103". I tried searching for it, but not successful so far. I even tried EXECUTE IMMEDIATE statement, putting some script blocks inside it - not working so far.
I will appreciate any hints/help on approaching my situation.
P.s. one of my first attempts is below:
CREATE OR REPLACE PROCEDURE export_to_csv (SOURCE IN VARCHAR2, EXPORT_PATH IN VARCHAR2) is
BEGIN
spool on;
set feedback off;
set heading off;
set sqlformat csv;
spool EXPORT_PATH;
select * from SOURCE;
spool off;
END export_to_csv;
Nope, that won't work. SPOOL, as well as all SET commands you use, are SQL*Plus.
Stored procedure is PL/SQL, so - if you want to do it from there, you'll have to use UTL_FILE package. The result will be on the database server, not your local PC.
Alternatively:
put those SPOOL, SET, SELECT, ... commands into a .SQL file on the database server
create a database job using DBMS_SCHEDULER package which is capable of running operating system files. On MS Windows, you'd call CMD which establishes connection to the database using SQLPLUS executable and calls your .SQL script (using #)
just like in the previous option, the result will be on the database server, not on a local PC
See which option you prefer.
Maybe it would be simpler to create that .SQL file and give it to all your colleagues who'd then run it on their PCs and get the result locally.
I am having a problem using host() command in oracle procedure.
I have written very simple oracle code.
CREATE OR REPLACE PROCEDURE
run_command(command_i IN VARCHAR2)
IS
l_message VARCHAR2 (100);
BEGIN
l_message := 'cmd ' || command_i;
host(l_message);
END run_command;
when host(l_message); is eliminated works fine.
Whats the problem and is there anyway to create a routine which uses host()?
The HOST command is only available in SQL*Plus and not from PL/SQL.
You can use Java stored procedure to call call OS commands. Oracle released a white paper on calling OS commands from within PL/SQL back in 2008 but there's plenty of other stuff out there (including Oracle Base, which is quite good)
Another clunky, but non-Java way would be to create DBMS_SCHEDULER ad-hoc EXECUTABLE job which is your HOST command (e.g. ls ), and then execute the job.
Note these run on the database server, not on your remote/local client.
Say I have a SQL script physically stored on the database server. Is there a SQL command I can send Oracle from an application to tell it to execute that script?
(Yes, I know this sounds ridiculous. I'm considering it as part of a work around of a very nasty problem that "shouldn't happen" but does.)
The easiest option would generally be to use the dbms_scheduler package to run an external job. This would let you invoke a shell script that started SQL*Plus, connected to the database, and ran your .sql script.
It would also be possible to create a Java stored procedure that uses Java's ability to call out to the operating system to run the same shell script. That tends to be a bit more of a security issue, though, since you're ending up granting the owner of this procedure privileges to run any command on the database server as the oracle user. That would include things like connecting to the database as SYSDBA or corrupting the database (accidentally or intentionally) so it's something that auditors would generally frown upon.