I am attempting to create a View in PhpPgAdmin (PostGreSQL db) which has the following SQL statement:
DELETE FROM myTable WHERE myTable.error IS NULL;
PhpPgAdmin gives me the following error:
ERROR: syntax error at or near "DELETE" at character 59
In statement:
CREATE OR REPLACE VIEW "Schema1"."Delete empty errors" AS DELETE FROM myTable WHERE myTable.error IS NULL;
As far as I can tell this SQL statement is valid, and I have delete privileges for the table. Is the DELETE statement not allowed in Views? Any ideas what I am doing wrong?
Views are used to display the data from SELECT statements only (usually when the SELECT is complex). Views cannot contain DELETES, UPDATES, or INSERTS.
Perhaps you want a function?
EDIT: As OMG Ponies points out, you can have updateable views, but thats where you would issue a DELETE to an existing view and then use a RULE to rewrite the query as a DELETE.
And please, please don't wrap a function call to do a DELETE as a side effect in a view. Its unexpected and Jesus shoots a puppy every time this happens.
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 database with three views. I am trying to execute a command to drop all three at once.
The Impala Guide shows it is possible to drop one view at a time using
DROP VIEW IF EXISTS mydb.view_name
But it does not suggest a method for dropping more than one view, the the same time this page from the Guide does not suggest this would be a restriction .
If I were using SQL server (and other versions of SQL), I could follow the method shown in this tutorial, separating the views by a ,.
DROP VIEW IF EXISTS
mydb.view_v1,
mydb.view_v2,
mydb.view_v3;
I would expect this to drop the three views from the database.
However when I try this in Impala I get the below error:
AnalysisException: Syntax error in line 2:undefined: ...exists mydb.view_v1, mydb.view_v2, mydb... ^ Encountered: COMMA Expected: ADD, ALTER, AS, CACHED, CHANGE, COMMENT, DROP, FROM, LIKE, LOCATION, PARTITION, PARTITIONED, PRIMARY, PURGE, RECOVER, RENAME, REPLACE, ROW, SELECT, SET, SORT, STORED, STRAIGHT_JOIN, TBLPROPERTIES, TO, UNCACHED, VALUES, WITH CAUSED BY: Exception: Syntax error
and all views remain.
Clearly, the error indicates that in Impala terms your statement is not syntactically correct (and not supported).
The only way I can think of to simulate something similar to what you need is to place all views into a separate database, and then run a DROP DATABASE ... CASCADE. I expect this operation to behave atomically, i.e either succeed of fail as a single unit.
I saved a SQL table before deleting some information from it with the sql statment:
select * into x_table from y_table
After doing some operations, I want to get back some information from the table I saved with the query above. Unfortunately, MS SQL Server MGMTS shows an error saying that the table does not exist.
However, when I put the drop statement, the table is recognized - and the table is not underlined.
Any idea why this table is recognized by the drop table statement and not the select from statement. This seems strange for me.
EDIT:
Thank you
It may be that the table isn't underlined in your drop table command because its name is still in your IntelliSense cache. Select Edit -> IntelliSense -> Refresh Local Cache in SSMS (or just press Ctrl+Shift+R) and see if the table name is underlined then.
Edit:
Another possibility is that your drop table command might be in the same batch as another statement that creates the table, in which case SSMS won't underline it because it knows that even though the table doesn't exist now, it will exist by the time that command is executed. For instance:
None of the tables one, two, or three existed in my database when I took this screenshot. If I highlight line 6 and try to run it by itself, it will fail. Yet you can see that two is not underlined on line 6 because SSMS can see that if I run the whole script, the table will be created on line 5. On the other hand, three is underlined on line 9 because I commented out the code that would have created it on line 8.
All of that said, I think we might be making too much of this problem. If you try to select from a table and SQL Server tells you it doesn't exist, then it doesn't exist. You can't rely on IntelliSense to tell you that it does; the two examples above are probably not the only ways that IntelliSense might mislead you about the current status of a table.
If you want the simplest way to know whether an object with a given name (like x_table) exists, just use:
select object_id('x_table');
If this query returns null, x_table doesn't exist, regardless of what IntelliSense is telling you. If it returns non-null, then there is some object out there with that name, and then the real question is why your select statement is failing. And to answer that, I'd need to see the statement.
A lot of posts like this, you have to copy in 2 statements :
CREATE TABLE newtable LIKE oldtable;
INSERT newtable SELECT * FROM oldtable;
I have a database user with read only permissions for table example_table.
Select * from example_table;
Works fine.
insert into example_table values('example');
Fails as expected. "insufficient privileges"
drop table example_table;
Fails with error message "table or view does not exist"
My question is. Why do the last two examples not both fail with "insufficient privileges" why when used in the ddl statement can it not even see the table?
Oracle 10g
Thank you.
Your SELECT would fail without a synonym, so you're not selecting directly from the table, but through a synonym.
DROP TABLE is DDL, and synonyms can't be used in most DDL statements. So in your case the statement goes after a real object (by default in the current schema if you have not specified an owner), doesn't find any object by that name, hence the (admittedly unhelpful) error message.
If instead you had written:
drop table owner.example_table;
Then you would have received the expected error message.
I have lost a trigger. I know it is active, since when I try to change a field, it restores its value back, and from the SQL Server Management Studio I can see that when I execute the query, an extra one is executing (the trigger one).
I tried SELECT * FROM sys.triggers WHERE 1 = 1 but it does not return anything. Also, I know the name of the trigger, but when I try to ALTERit returns an error saying that
the name of the object 'myTrigger' is not valid.
And if I try to DROP TRIGGER myTrigger ON DATABASE
Trigger 'myTrigger' can not be removed because it does not exists, or the user has not enough priviledges.
Ok, as Lieven said, I was not querying the right database... This is odd, since the query had the DB defined on it
ALTER TRIGGER myTrigger
ON [DB].[dbo].[table]
But the upper select of the SQL Server Management Studio was pointing to other DB...
Edit:
I have been investigating a little bit (trying to clean my image), and I found a weird behaviour on SQL Server Management Studio.
If you execute a query like:
UPDATE [DB].[dbo].[table] SET column = 'value' WHERE column2 = 'foo'
It executes the query in the right DB. No matter what DB is pointed by the upper select.
But, if you try to do the same, with a trigger, you must have the upper select pointing the right DB, or you will face the same problems I had.
I had a subtle error kind of like yours; I did something like this:
CREATE TRIGGER [TrigCustomerInsertDelete]
ON [mobile].[Customers]
AFTER INSERT, DELETE
AS
select 'I' [ACTION],* from inserted
select 'D' [ACTION],* from deleted
GO
and then later tried to update it with:
ALTER TRIGGER [TrigCustomerInsertDelete]
and got this error: Invalid object name
The problem was that I did not specify the schema on the trigger (thinking it would just be dbo), but the table does have a schema. So, I figured out the error after including the schema on the trigger.
CREATE TRIGGER [DBO].[TrigCustomerInsertDelete]
This gave me the following error: Cannot create trigger 'DBO.TrigCustomerInsertDelete' because its schema is different from the schema of the target table or view.
I know this is an old post, but hopefully it will help someone else.