I am creating a view on a bigQuery Table. The view works fine, until I truncate that table and put new data in it. I get the following error:
"Query Failed Error: A view from this query references an old version of
a table that might be incompatible. Please delete and re-create
repcore-dev:views.listings."
If I run the query that defines the view, it works. If I re-create the view with the same query, it works. But my question is why this is necessary. For us the real value in the view is that it provides an abstraction of the table data (even when that data is re-populated).
Related
I have to run a script for a company. I just get the same error every time.
The query:
DELETE FROM WMO
WHERE (clientnr = ****** AND number_message = *****)
The error:
ORA-01752: cannot delete from view without exactly one key-preserved
table
What did I wrong?
Thnx!
Database views are in general projection of one or more tables. It is a SELECT statement over one or more tables to be specific. For database engine it is impossible to decide what it should delete and from which table unless the view is constructed from single table.
The best solution is to run DELETE command against tables that are used to construct the view.
Additional information:
ORA-01752: cannot delete from view without exactly one key-preserved table
I want to be able to make CTE to make the below SQL work, I am getting the error
ERROR: Cannot replace a normal view with a late binding view for the below SQL, any way I could change it up so that it doesnt bind with schema views?
CREATE OR REPLACE
VIEW "dev"."XXBRK_DAILY_FX_RATES" ("F_C", "CURRENCY", "C_D", "C_R") AS
SELECT DISTINCT GL.GL_R.F_C, GL.GL_R.CURRENCY,
GL.GL_R.DATE, GL.GL_R.C_R
FROM GL.GL_R
with no schema binding
WHERE GL.GL_R.C_T='Corporate'
UNION ALL
SELECT DISTINCT GL.GL_R.F_C, GL.GL_R.F_C CURRENCY, GL.GL_R.DATE, 1
FROM GL.GL_R;
So you seem to have a statement issue. The last 4 lines are after the ';' and not part of the statement being run. I'm guessing that these are extraneous and posted by mistake.
Views on Redshift come in several types - normal and late binding are 2. The view "dev"."XXBRK_DAILY_FX_RATES" seems to already exist in your cluster so your command is trying to replace it, not create it. The error message is correct, you cannot replace a view with a view of a different type. You need to drop the view, then recreate it as late binding.
Now be careful as other objects dependent on this view will be impacted when you drop it (especially if you CASCADE the drop). When you drop and recreate the view it is a new object in the database but replacing a view just make a new definition for the same object. Understand the impacts of drop to your database before you execute it.
When you create a view, the column structure of the view is created and stored, and thus you can see it in object explorer:
When you alter the source data tables, sometimes things go wacky, because the view may have been built with "Select *" yet the schema created for you has the old information without the additional columns.
Does SQL Server have an easy way to rebuild the view schemas?
Do not use SELECT * in views. I say this as someone who has spent much too much time (in the past) debugging views that had this "feature".
When you do create a view in a production system, create it with SCHEMABINDING:
SCHEMABINDING
Binds the view to the schema of the underlying table or tables. When SCHEMABINDING is specified, the base table or tables cannot be modified in a way that would affect the view definition. The view definition itself must first be modified or dropped to remove dependencies on the table that is to be modified.
Although this adds an extra step when trying to modify tables, the increased resilience of the system is worth it.
I wrote simple update query as below
update table_name set name = 'new name
that gave to me error
SQL Error: ORA-01732: data manipulation operation not legal on this view 01732. 00000 - "data manipulation operation not legal on this view"
after that i check
select * FROM USER_OBJECTS WHERE OBJECT_NAME='table_name'
that list TABLE and MATERIALIZED VIEW same as the 'table_name'
I know materialized view is not possible to update but table should update
please let me know how can i update table using simple above update query
You cannot update the materialized view or the physical table it uses for storage. You can only update the table(s) the view is built against. Presumably you know those; if not you can get the view definition from the data dictionary, or with dbms_metadata.get_ddl.
Updating the view or it's backing table doesn't make sense anyway. Even if you were allowed to, any changes you made would be lost the next time the view is refreshed.
If you don't want the materialized view to ever be refreshed again then you could drop that with the preserve table option, which would leave behind just the physical table - and you then update that. But if you change your mind you'd have to recreate the view and specify the existing table.
I have a table T_SG_LTA_TRANSACTION_TYPE in source database.
I want to move it into a target database.
I have created a materialized view log in source database.
CREATE MATERIALIZED VIEW LOG ON T_SG_LTA_TRANSACTION_TYPE WITH PRIMARY KEY, ROWID;
Then I created materialized view in target database with following query.
CREATE MATERIALIZED VIEW T_SG_LTA_TRANSACTION_TYPE
ON PREBUILT TABLE
REFRESH FAST ON DEMAND
FOR UPDATE
AS
SELECT TRANSACTION_ID,
TRANSACTION_DESCRIPTION,
FILE_TYPE_ID
FROM T_SG_LTA_TRANSACTION_TYPE#EBAODWH_SRC_1_GS_AIG;
But when I refresh materialized view , I am unable to load the data which is already present in T_SG_LTA_TRANSACTION_TYPE(SOURCE DB).
BEGIN
DBMS_MVIEW.refresh('T_SG_LTA_TRANSACTION_TYPE');
END;
The data which is updated in source table after creation of materialized view, is only loading to materialized view . But I want to get whole data from source table(modified and unmodified) into materialized view. And I need this unmodified data only once when mview is created. Please suggest the solution. Thanks in advance.
You seem to be using the ON PREBUILT TABLE clause incorrectly:
The ON PREBUILT TABLE clause lets you register an existing table as a preinitialized materialized view.
And
Caution:
This clause assumes that the table object reflects the materialization of a subquery. Oracle strongly recommends that you ensure that this assumption is true in order to ensure that the materialized view correctly reflects the data in its master tables.
You're essentially saying that T_SG_LTA_TRANSACTION_TYPE already exists on the target database - not the source - and contains the current state of the source table; which, since you're missing data, is not true.
When you refresh Oracle is only looking for changes since the view was created, as it's supposed to; it relies on the MV log to identify what has changed.
Drop the MV in the target database, without the preserve table clause, and then recreate it without the on prebuilt table clause.
Make sure you're dropping the right thing in the right database/schema, of course...
It isn't clear if the (empty) table already existed in your target DB before you started; or you've run this a couple of times and dropped the MV with preserve table - and either the source was empty last time, or you truncated the target table afterwards - or perhaps you tried to export/import the initial state but just got the metadata and not the data. If the table you said existed on the target DB did not, in fact, exist then Oracle would have thrown an ORA-12059 exception when you tried to create the MV. I suspect you'd created an empty table and then tried to convert it to an MV, but if you do that it won't get any data from the source DB, as you've seen.