I am looking for options on how can I inherit the table level comment directly into a view when it is pointing to the delta table.
I do see we can add comment to the view with the command but not able to find anything where we can inherit the comment from the table itself automatically instead of manually adding it.
Related
Oracle EBS R12.2.9
I have to add a new column to an editioning view of a custom table in oracle EBS R12.2.9.
Table was created like this...
From AMTO: create table amto.mci_jjtest1(a number)
From APPS: exec ad_zd_table.upgrade('AMTO', 'MCI_JJTEST1') -- This creates editioning view and also synonym under APPS
Now, new column B number with data type, needs to be added to the table, and the editioning view needs to be modified to add that column to the editioning view. Kindly let me know what commands and steps, I need to follow. I understand the traditional approach, where we would alter table to add column, and create or replace view to add the column to the SELECT, Not sure how to add column to table and editioning view the correct recommended way. Please suggest.
For table alterations - after running the DDL run below script to regenerate the editioning view for syncing any table changes.
exec AD_ZD_TABLE.PATCH('AMTO','MCI_JJTEST1')
An external system granted to my system a view named V_EXT so that I can make selections on it, reading all its content:
SELECT *
FROM V_EXT;
this view has a lot of fields and I would like to create an empty table in my system with the exactly same attributes of this view (same names and same types). Is there a way to do this without simply guessing from the content I received what each attribute is?
I am using Oracle SQL Developer.
With Code.
create table objects_copy2
as
select *
from all_objects
where 1=2; -- add this line if you want NO data, otherwise you get all the data too
With SQL Developer specifically, it's actually harder. You would need to find the underlying OBJECT(s) used in the query. Then look up those data types, and manually build out your CREATE TABLE statement.
CREATE TABLE AS SELECT is the way to go. (Docs)
Note there are some limitations, for example this won't pick up Identity Column definitions from the source table used in the view.
An example:
Something failed while we were swapping disks for our ClickHouse database. When ClickHouse started, I had to attach all the tables as they were not there via ATTACH TABLE IF NOT EXISTS ....
Is there a way to do the same for materialized views? I couldn't find a way how to do that and when I try to create it from scratch (CREATE MATERIALIZED VIEW IF NOT EXISTS ..., ClickHouse says:
Data directory for table already containing data parts - probably it
was unclean DROP table or manual intervention. You must either clear
directory by hand or use ATTACH TABLE instead of CREATE TABLE if you
need to use that parts.
So the files are still there but dunno how to attach the view.
You need to attach the ".inner." table first.
Materialized views do not store data, they create a special table with the engine that you choose when you create the view. The name of that table is ".inner.the_name_of_the_view".
So you need to attach that table first, and then attach the materialized view.
When attaching other tables and restarting the ClickHouse server, the views got attached automatically. I was trying to attach .inner tables too but it didn't let me.
If I have table T with 10 columns and create materialized view log with only 3 of them as well as materialized view with those 3, why when I updated ANY column in the table (besides those in the log) the record is inserted into MLOG$_T ? Is there a way to avoid?
Thanks
No, you can't avoid it. The primary purpose of the log is to identify the rows that have changed, not the changed data itself (although you can include that in the log as well). The process for maintaining the log doesn't know anything about the view(s) that might be created that will use the logs, so it has to maintain the log for any change in the table.
This of it this way: suppose you later create another materialized view on the same table that uses other columns. If the log is to be useful, it must maintain information about changes for those rows as well. After all, you can only create one log per table.
I'm wondering if its possible to create a view that automatically checks if there is a new monthly created table and if there is include that one?
We have a new table created each month and each one ends with the number of the month, like
table for January: table_1
table for February: table_2
etc...
Is it possible to create a view that takes data from all those tables and also finds when there is a new one created?
No, a view's definition is static. You would have to replace the view each month with a new copy that included the new table; you could write a dynamic PL/SQL program to do this. Or you could create all the empty tables now and include them all in the view definition; if necessary you could postpone granting any INSERT access to the future tables until they become "live".
But really, this model is flawed - see Michael Pakhantsov's answer for a better alternative - or just have one simple table with a MONTH column.
Will be possible if you instead of creating new table each month will create new partition for existing table.
UPDATE:
If you have oracle SE without partitioning option you can create two tables: LiveTable and ArchiveTable. Then each month you need move rows from Live to ArchiveTable and clean live table. In this case you need create view just from two tables.
Another option is to create the tables in another schema with grants to the relevant user and create public synonyms to them.
As the monthly tables get created in the local schema, they'll "out-precedence" the public synonyms and the view will pick them up. It will still get invalidated and need recompiling, but the actual view text should need changing, which may be simpler from a code-control point of view.
You can write a procedure or function that looks at USER_TABLES or ALL_TABLES to determine if a table exists, generate dynamic sql, and return a ref cursor with the data. The same can be done with a pipelined function.