How to bind multiple tables to single DM form? - oracle

I have a DM Form type page, where I would like to show and update values from different tables. By default when I created page, I have been asked for data source, specified only one of the tables, which in fact created process in After Header of type Automated Row Fetch. Also in After Submit a process of type Automatic Row Processing (DML) is created. When I add an item in the page from different table, obviously I am getting an error that the column not found in that table. How can I add more tables into that page, so they will be fetched and updated properly?
There is a common column in all tables, to identify which record I would like to show from each table.

I would like to show and update values from different tables
[...]
There is a common column in all tables, to identify which record I would like to show from each table.
Maybe are you looking for a simple JOIN on your various tables?
Based on Oracle's HR example schema, if you need to display both departments and employees names, you write something like that as your report query:
SELECT department_name as dep_name,
first_name || ' ' || last_name as emp_name
FROM HR.DEPARTMENTS JOIN HR.EMPLOYEES
USING(DEPARTMENT_ID)
In order for this to be usable from APEX form builder, you have to wrap it in a VIEW:
CREATE VIEWS MY_VIEW AS SELECT .... FROM ... JOIN ...
I can't guarantee that the view will be update-able out-of-the-box as Oracle has very specific rules for inherently updatable views -- especially for join views. However, you might be able to make your view updatable anyway by using an INSTEAD OF trigger. If you decide to go that way, maybe worth considering asking an other question on that specific topic if needed.

Related

Why I can't able to create outer join in bulk delete job? even for views which is not listing on bulk delete

I tried to create a view in powerapps table to perform bulk delete action on it. The view that defines outer join like,
I want to get the table Order values which should not be present in the Invoice table, but it should have a relation with the table Invoice (which means the record should be present in table Order but not in table Invoice).
For this, I had the option to create a view by applying the above condition was,
And the above condition is working fine and results were expected. But the problem is when i added the above condition for creating a particular view ( XYZ view) which is not listing on Bulk delete wizard for that entity( here the entity is order).
To overcome this issue what i can do?

Is there a way to give a "second name" to a table in Hive so that a user can refer to either name of the table and would retrieve the same thing?

I would like to be able to refer to tables with a certain naming schema to make my code uniform, but I am pulling tables from different environments with different naming schema. If I want all my tables to have names like example_table_1 and example_table_2, but the second one is something like TB_ex_2, is there a way to give that table an attribute so that I can also call select * from database.example_table_2, and it will know to refer to TB_ex_2?
I understand that I can alias tables, e.g. select * from TB_ex_2 example_table_2, but I am trying to avoid that. Renaming each table is also not an option, because those names need to be retained to identify which environment they are coming from.
Hive does not support synonyms. The workaround is to create a view:
CREATE VIEW table2
AS SELECT * from table1;
Also you can create many tables on top of the same location(data).

Updating Resultset that points to an Oracle view

Is it possible to do updates via Resultset to an Oracle view? Asking as my code is giving me insufficient priviledge error when it does the rs.updateRow() call. I have checked and I definitely have access to the table/view.
The code looks like:
white (rs.next()) {
int updateStatus = getPSCforAction(status);
rs.updateInt("SPSC", updateStatus);
rs.updateRow;
}
The SELECT statement changes depends on operation but it will always be querying an Oracle view (and in some cases multiple views). My main question is whether updating via resultSet can be done to an Oracle view (or views)?
To answer your question one must see a definition of you view and a SELECT statament that is used to produce the resulset in your Java code. Without looking at this it is hard to give the answer
Anyway, generar rules and limitations are described in the Oracle Database JDBC Developer's guide:
Result Set Limitations
The following limitations are placed on queries for enhanced result
sets. Failure to follow these guidelines results in the JDBC driver
choosing an alternative result set type or concurrency type.
To produce an updatable result set:
A query can select from only a single table and cannot contain any
join operations.
In addition, for inserts to be feasible, the query must select all
non-nullable columns and all columns that do not have a default value.
A query cannot use SELECT * . However, there is a workaround for this.
A query must select table columns only.
It cannot select derived columns or aggregates, such as the SUM or MAX
of a set of columns.
To produce a scroll-sensitive result set:
A query cannot use SELECT *. However, there is a workaround for this.
A query can select from only a single table.
Scrollable and updatable result sets cannot have any column as Stream.
When the server has to fetch a Stream column, it reduces the fetch
size to one and blocks all columns following the Stream column until
the Stream column is read. As a result, columns cannot be fetched in
bulk and scrolled through.
They vaguely write that:
A query can select from only a single table and cannot contain any
join operations.
Could be that they mean "exlusively from tables, but not views", but also they could mean: "from tables and views", nobody knows, one must test this.
Another possible problem - your view may not be updatable, that is it doesn't conform to the following rules:
Notes on Updatable Views The following notes apply to updatable views:
An updatable view is one you can use to insert, update, or delete base
table rows. You can create a view to be inherently updatable, or you
can create an INSTEAD OF trigger on any view to make it updatable.
To learn whether and in what ways the columns of an inherently
updatable view can be modified, query the USER_UPDATABLE_COLUMNS data
dictionary view. The information displayed by this view is meaningful
only for inherently updatable views. For a view to be inherently
updatable, the following conditions must be met:
Each column in the view must map to a column of a single table. For
example, if a view column maps to the output of a TABLE clause (an
unnested collection), then the view is not inherently updatable.
The view must not contain any of the following constructs:
A set operator
A DISTINCT operator
An aggregate or analytic function
A GROUP BY, ORDER BY, MODEL, CONNECT BY, or START WITH clause
A collection expression in a SELECT list
A subquery in a SELECT list
A subquery designated WITH READ ONLY Joins, with some exceptions, as
documented in Oracle Database Administrator's Guide
In addition, if an
inherently updatable view contains pseudocolumns or expressions, then
you cannot update base table rows with an UPDATE statement that refers
to any of these pseudocolumns or expressions.
If you want a join view to be updatable, then all of the following
conditions must be true:
The DML statement must affect only one table underlying the join.
For an INSERT statement, the view must not be created WITH CHECK
OPTION, and all columns into which values are inserted must come from
a key-preserved table. A key-preserved table is one for which every
primary key or unique key value in the base table is also unique in
the join view.
For an UPDATE statement, the view must not be created WITH CHECK
OPTION, and all columns updated must be extracted from a key-preserved
table.
For a DELETE statement, if the join results in more than one
key-preserved table, then Oracle Database deletes from the first table
named in the FROM clause, whether or not the view was created WITH
CHECK OPTION.

Find references to specific column in Oracle in Jobs and Procedures

I'm looking for a query allowing me to query all the tables, views, JOBS, and PROCEDURES in the oracle database. I've found some links to queries that will work for the tables and views but I need jobs and procedures. If one query can't be used for all this, I need at least job and procedures.
Here is what I found for the tables and views:
Select TABLE_NAME, COLUMN_NAME from user_tab_columns
TIA
My guess is that you want something like
SELECT name, type, line, text
FROM user_source
WHERE lower(text) like lower('%<<column name>>%');
That will show you any line of code in any pL/SQL object (package, package body, procedure, function, trigger, type, etc.) that contains the column name. If there are multiple tables with identically named columns (i.e. a column name is found in many different tables), all instances will be identified. There isn't a really great way, short of inspecting the code, to figure out which queries refer the name column in one particular table. You could potentially look to see whether the NAME and TYPE from USER_SOURCE appear in DBA_DEPENDENCIES as referencing the particular table you're interested in. But that just shows you table-level dependencies at an object level and your object may depend on a large number of different tables.

DB project - improving performance with relationships

I have two tables, let's call them TableA and TableB. One record in TableA is related to one or more in TableB. But there's also one special record within them in TableB for each record from TableA (for example with lowest ID), and I want to have quick access to that special one. Data from both tables aren't deleted - it's a kind of history rarely cleared. How do that the best in terms of performance?
I thought of:
1) two-way relationship, but it will affect insert performance
2) design next table, with primary key as FK_TableA (for TableA record exactly one is "special") and second column FK_TableB and then create view
3) design next table, with primary key as FK_TableA, FK_TableB, make FK_TableA unique and then create view
I'm open for all other ideas :)
4) I'd consider an indexed view to hide the JOIN and row restriction
This is similar to your options 2 and 3 but the DB engine will maintain it for you. With a new table you'll either compromise data integrity or have to manage the data via triggers

Resources