CREATE VIEW CARAVAN AS
SELECT ANNUAL_RENT, BOOKING_FEE
FROM CARAVAN
WHERE ANNUAL_RENT < 3000
this is my failed sql. the error is
ORA-00928: missing SELECT keyword
Try running just the SELECT statement:
SELECT ANNUAL_RENT, BOOKING_FEE
FROM CARAVAN
WHERE ANNUAL_RENT < 3000
And see if that returns a result, or if it generates an error.
My suspicion is that CARAVAN is a view that is INVALID. You can check that with a query from a dictionary view, e.g.
SELECT *
FROM dba_objects
WHERE object_name = 'CARAVAN'
If you don't have privileges on dba_objects, then reference the all_objects instead.
The referenced CARAVAN object is either an object in your schema, a public synonym, or its an invalid reference.
As Alex Poole mentioned, it's possible to create a view that has invalid syntax, by using a CREATE FORCE VIEW statement. (I suspect that the referenced object CARAVAN is a view that contains invalid syntax.)
Identifiers in Oracle have to be unique within a schema. It's very strange that you would be creating a view named CARAVAN that references an object already named CARAVAN. It's not clear what problem you are trying to solve with this particular CREATE VIEW statement.
Related
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.
I have a few base views created WITH NO SCHEMA BINDING. On top of one of these views I wanted to create a master view, however that forces me to create it without the WITH NO SCHEMA BINDINGclause- I am assuming due to the dependency on the base view.
After I create the master view, if I query it via select * from master_view everything works.
However, querying it a few hours later - I receive a relation "does not exist" error..
On the other hand, select * from any of the non master views (created WITH NO SCHEMA BINDING never fails..
Any idea why this is happening, and how I can make sure the master view exists permanently after creating it once?
According to https://forums.aws.amazon.com/thread.jspa?threadID=263944 it looks like the following error: 'Invalid operation: All the relation names inside should be qualified when creating VIEW WITH NO SCHEMA ' is caused by some of the tables being joined not specifying the schema to which the table belonged.
For example: JOIN table should be JOIN schema.table.
Specifying the schema allowed me to use with no schema binding when creating the master view and fixed my problem
I created view with name 'ATM_BRANCH' but there was some error in sql statement so view did not created. But now after correcting error, I tried again but it gives me error 'There is already an object named 'ATM_BRANCH' in the database'. Then I see the views in Object explorer and there is no view with this name. I need to create the view with same name. What to do?
My guess is that the view is actually still there, in some form. First run this to confirm:
SELECT EXISTS(SELECT 1 FROM sys.views WHERE name = 'ATM_BRANCH' AND type = 'v');
If that returns true, then drop the view:
DROP VIEW ATM_BRANCH;
Based on your comment, and Gordon's correct guess, ATM_BRANCH is actually a table. So, if you want to name a view ATM_BRANCH, you'll have to drop the table first:
DROP TABLE ATM_BRANCH;
I am hitting my head against the wall for a weird error I am getting in VS2012.
I have a database project which includes some Synonyms. They are basically table references to another database in order to avoid dynamic SQL generation. I already added the required reference database for the Synonyms. Everything works great except a couple of views that are using some of those Synonyms! Since I am using the same Synonyms in my stored procedures and they are not causing any build failure, I am not sure why the views are causing problem.
The error message says: "SQL05313: Synonym 'xxx' refers to an invalid object.'
Here is a sample code -
dbo.MyTable.sql...
CREATE SYNONYM [dbo].[MyTable] FOR [$(FOO_DB)].[dbo].[MyTable];
dbo.MyProc
CREATE [dbo].[MyProc] AS SELECT col1, col2, col3 FROM [dbo].[MyTable];
SUCCESS: this works
dbo.MyView.sql...
CREATE VIEW [dbo].[MyView] AS SELECT col1, col2, col3 FROM [dbo].[MyTable];
ERROR: SQL05313 Synonym '[dbo].[MyTable]' refers to an invalid object.
Has anyone else faced this issue? If yes, I appreciate your assistance :)
For some reason, reference errors in SPs are treated as warnings, while the same in views is treated as an error. Thus the error just means that the reference to $(FOO_DB) is not working - double check that the variable reference is set up correctly.
If you are referencing another DB project, it must be compilable to .dacpac individually (e.g. you cannot create circular references). If you really need circular reference (view in FOO_DB1 references FOO_DB2, and view in FOO_DB2 references FOO_DB1), look into composite objects (database reference of type same database).
I got this error, and I eventually found that I had run CREATE SYNONYM fred FOR ... instead of CREATE SYNONYM **dbo**.fred FOR ...
It therefore created the synonym in my personal schema, instead of dbo, and this stopped the CREATE VIEW.
I know that your code includes [dbo].[MyTable], but do you have an identical synonym in your own schema, from a previous CREATE SYNONYM command that did not include the [dbo], which might be confusing the CREATE VIEW command?
What determines whether an Oracle object (table, view, etc.) is required to be qualified with a schema name (for example, schema.table_name, or schema.view_name, etc.)? At times I am able to access a remote objects (via a DB link) without having to qualify the schema, but other times, I receive an error stating that the "table or view doesn't exist", and to correct this, I must qualify the schema name.
I am aware that it is a best practice to always qualify a schema name, but I am just curious why I am able to access certain remote objects without a qualified schema, and others only with a qualified schema.
From the Oracle documentation:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10759/sql_elements009.htm
The following example illustrates how Oracle resolves references to objects within SQL statements. Consider this statement that adds a row of data to a table identified by the name departments:
INSERT INTO departments
VALUES
(
280,
'ENTERTAINMENT_CLERK',
206,
1700);
Based on the context of the statement, Oracle determines that departments can be:
A table in your own schema
A view in your own schema
A private synonym for a table or view
A public synonym
Oracle always attempts to resolve an object reference within the namespaces in your own schema before considering namespaces outside your schema. In this example, Oracle attempts to resolve the name departments as follows:
First, Oracle attempts to locate the object in the namespace in your own schema containing tables, views, and private synonyms. If the object is a private synonym, then Oracle locates the object for which the synonym stands. This object could be in your own schema, another schema, or on another database. The object could also be another synonym, in which case Oracle locates the object for which this synonym stands.
If the object is in the namespace, then Oracle attempts to perform the statement on the object. In this example, Oracle attempts to add the row of data to departments. If the object is not of the correct type for the statement, then Oracle returns an error. In this example, departments must be a table, view, or a private synonym resolving to a table or view. If departments is a sequence, then Oracle returns an error.
If the object is not in any namespace searched in thus far, then Oracle searches the namespace containing public synonyms. If the object is in that namespace, then Oracle attempts to perform the statement on it. If the object is not of the correct type for the statement, then Oracle returns an error. In this example, if departments is a public synonym for a sequence, then Oracle returns an error.
What it's saying is that Oracle will check locally for objects you call before expanding its search outwards.
It may well be that there are public (or your own private) synonyms on some of your remote objects allowing you to reference them directly whereas those without the synonyms you'll have to fully qualify.
It depends on what username have you used when you logged in. Or what username was used when the database link was created/configured.
See, for each schema, there is a user. If you logged in as a user "XYZ", then you do not need to qualify object within the "XYZ" schema.