In psql we have PL/Perl to communicate with external program when the new row is inserted into our table. Like that is there any way (procedural language ) to communicate with external program in Oracle . For achieving this things, what should I do.....?
Can any one help me out of this problem.....
Oracle offeres packages to communicate externally to a file, or pipe. Create a trigger to write to one of these when a row is updated. Be careful how you deal with failures in this code so you don't lock up the database or rollback the transaction if you external program is not available. Checkout out the utl packages.
The most suitable answer to your rather vague question depends on the kind of problem you want to solve when you mention communicate with external programs.
Please check documentation about Oracle's Database Change Notification, you will find your answers there.
Related
Is it possible to have a dry run in Tibco for the JDBC Update activities? Meaning that I want to run those activities, but not actually update the database.
Even running in test mode if it's possible will be good.
The only option I see is having a copy of the targeted tables in a separe schema, duplicate the data, and temporary align the JDBC connection of you activity on this secondary, temporary/test database.
Since you can use global variables, no code is changed between test and delivery (a typical goal), and you can compare both DB tables to see if the WOULD HAVE ran well...
I think I found a way. I haven't tested it yet, but theoretically it should work.
The solution is to install P6Spy and to create a custom module that will throw an exception when trying to execute an INSERT/UPDATE.
You could wrap the activity into a transaction group and rollback whenever you only want to test the statement. Otherwise just exit the group normally so the data gets commited.
Using Toad for Oracle 10.6 with DB Admin Add-in. For our migration process Dev to QA to Prod, we are starting to use the Schema Compare Module to generate the Sync Script DDL. After execution, we want to store the Sync Scripts for historical purposes. Due to policy, we are unable to copy these much of anyplace. Even the Windows server where toad runs is write-restricted.
I am thinking I could create a table with a CLOB column and store the scripts there, unless you folks tell me that this is a Really Bad Idea. I am looking for any tips on things like handling embedded special characters, or any other pitfalls that I may encounter.
Thanks,
JimR
Doing the best with what you have is a good thing. If management won't let you have version control, then jamming it in the database is better than nothing at all. The important thing is to create a process, document it, and follow it for deployments.
As for using schema differences to deploy, take a look at:
http://thedailywtf.com/Articles/Database-Changes-Done-Right.aspx
Try to be more clear, I'm in lack of ideas in this problem, even it sounds like a classic.
My application is running on weblogic 10.3.3 application server, and for database I am using Oracle database 11g. My problem is that there is table in db, let's say "user.", there is column, let's say "columnA", in this table. This table is updating by some module of application.
What I want if when value of column is "abc.", then I have to show alert to console(IP). {IP can be retrieved from DB as it is configured in DB. this ip will be other linux system other than linux machine where oracle database is installed.} Updating is continuously done on my table from module of application. Please tell me from where should I start?, what should I read. I am not able to understand what should be approach. Any help is much appreciated.
A trigger on the table can call UTL_HTTP to communicate with another machine (eg call a RESTful API).
The architectural questions are :
This will happen PRIOR to the commit so you may get false alerts if a change is rolled back
If you wait for a response, it will slow the system down.
What do you do if you get an non-standard response (eg the other server isn't available)
I'm using BulkCopy method from ODP.NET to insert a DataTable to a temporary table.
If the temporary table is simple (no triggers or indexes) it works, fine, but as soon as I create an index or trigger, i get the "End-of-file on communication channel" error at BulkCopy.WriteToServer() method.
Any idea how could i fix this?
Thank you!
In case of an ORA-03113: end-of-file on communication channel, the server process dedicated to your session died because of a bug or error. The client process detects that the server process is missing and raises the ORA-03113. The server process has written its error message to the alert file. Check this file on the server to find out what went wrong. You may have to ask your DBA to do this for you.
Regards,
Rob.
I concur with the posters above. Check your alert log file. If you see an ORA-600 there, you (or your DBA) should contact Oracle support because you may need a patch.
Christian Shay
Oracle
Temporary tables in Oracle are almost always a bad idea. Can you re-design the program to use either a regular table or a PL/SQL collection?
I've contacted Oracle about this. Apparently it's a bug, that was fixed in 11g. They're now trying to release a patch
Instead of placing triggers on tables everywhere in an Oracle database, is there a Java API that I can use to read transactions off the Oracle transaction log?
My purpose is to be able to detect transactions going into a proprietary(vendor) database and react accordingly. We can't modify the database so that we do not void our maintenance contract.
Please help!
There is LogMiner which is SQL based (and so you could access through JDBC).
http://download.oracle.com/docs/cd/B19306_01/server.102/b14215/logminer.htm#sthref1875
Or you can look at Oracle Streams which reads the logs and generates 'logical change messages' into a queue from the log contents.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14229/strms_over.htm#i1006309
If you are running in *nix, there is a perl module that you could use to tail the file; then break down the lines for yourself.