i am creating a table in sqlserver database using query like "SELECT Table1.* INTO Table2 FROM Table1"
here Table2 created successfully but it is not showing my database
when i again fire this query than it gives error that Table2 is already created but i can't see this in my database
i am refreshing my database also
so please help me if anyone has solution..
#Ramesh has the right idea. In some situations (I think if your user is in the db_owner role?), SELECT INTO tables are created in the schema (the SQL 2005+ terminology) associated with your login. This may be something like YOURDOMAIN\username.Table2. If you go to select again from the same login, it will work fine, but chances are that other users will not be searching in your schema.
When in doubt, explicitly create the table in the dbo schema:
SELECT Table1.*
INTO dbo.Table2
FROM Table1
have you tried with the username.Table1, like
dbo.table
Its very important to append the username for any db object, it enforces the user to select the objects which he got permission to view
Related
Can someone explain the difference in semantics between the following:
select count(*) from dbo.SomeTable;
select count(*) from SomeTable;
select count(*) from ..SomeTable;
select count(*) from somedb..SomeTable;
select count(*) from somedb.dbo.SomeTable;
They all seem to yield the same results in my system.
More specifically I have this theory that somedb..SomeTable actually means:
the object SomeTable owned by the user I am currently connected as
in the database somedb.
Is this correct?
If so, given then that usernames appear to serve to partition table names into different namespaces, can't it be said that Sybase conflates the concept of a user to that of a schema? (since schemas are what other RDBMSs use to namespace tables?)
There is a user in my Oracle 12c database that has several views created from selecting columns from another user's tables. For example:
CREATE OR REPLACE FORCE EDITIONABLE VIEW "MYSER"."VIEW1" (column1, column2, column3)
AS SELECT (column1, column2, column3)
FROM OTHERSCHEMA.TABLENAME;
Now when running
select count(1) from MYSER.VIEW1
as sys user, I can see all the rows are there. However, as soon as I log into MYSER schema, and try to run the same select count statement, I either get a lower number or rows than the total, or no rows at all. (when doing this for several of the views done in the same fashion)
I have granted select on all of OTHERUSER's tables to MYUSER
This data was imported from another database. Not sure if that is what could be causing the issues.
EDIT: I have also tried granting
Grant execute on DBMS_RLS to MYUSER;
Thinking that it could be an issue with the partitions in the table. It could be something funky that the people that coded this application years ago enabled that I need to find out where they security levels or something in place.
Thanks!
A view is just a stored SQL statement.
When connected as myser
select * from view1;
should return exactly the same as
select column1, column2, column3 FROM OTHERSCHEMA.TABLENAME;
I have two tables arts and artsdetails.. artsId is the primary key in arts table foreign key in artdetails table. I am selecting values from both table but my query is giving error as
"Invalid object name 'artdetails'"
My query is:
SELECT arts.artsId, artdetails.mainImage
FROM artdetails
INNER JOIN arts ON artdetails.artsId = arts.artsId;
Please help.
You're probably not running the query in the database where these tables live.
If you're using SQL Server Management studio, look in the top left for a drop down containing the database names. It probably says 'master' (as that's the default). Select the one containing the tables you're using and re-run your query.
Failing that, check they're both running in the same schema as Tom suggests.
You can fully quality table names in your query like this:
SELECT a.artsId, ads.mainImage
FROM [DBNAME].[SCHEMA].artdetails ad
INNER JOIN [DBNAME].[SCHEMA].arts a ON ad.artsId = a.artsId;
Also using table abbreviations tidies things up a bit.
What I want to do is instead of writing:
Select something From [Parent].[dbo].[Table]
I want to declare the first 2 before I write the query, so when I have to use several selects I don't have to specify [parent].[dbo] all the time. What I remember is that you can do something like this:
use [parent].[dbo]
select something From tabel
This seems to generate a warning 102, at the ".". I've tried googling this but all I get is "use" while doing generated queries, nothing to do with database names.
The dbo part is implied. Just do this:
use [parent]
select something From tabel
As Damien_The_Unbeliever pointed out, the dbo part is only implied if dbo is the user's default schema.
Parent must be your Database.
So if you want to use a particular database without specifying it:
use [DataBase]
DBO is implied, but if you want to use another schema, you will need to specify the schema in your SQL, ala newschema.Table1
In case you aren't using it, you can also reduce the clutter in your code by using aliases for your tables, ala
SELECT a.Column1, a.Column2
FROM table1 a JOIN
table2 b ON a.Column1 = b.Column1
WHERE a.column1 = 'SomeValue'
where the a that follows the table1 is an alias for table1, basically your giving the table a nickname for this query. Same thing for the b, it is an alias for table2. This is much less cluttered than SELECT table1.Column1, table1.Column2 FROM table1
Hello I have a table on which I have denied SELECT privs to a user.
This table has a trigger which references the INSERTED table, basically doing an
AFTER UPDATE SET <table>.[UPDATED] = getdate()
WHERE ROWID IN SELECT ROWID FROM INSERTED
It is giving me an error though, saying "SELECT PERMISSIONS DENIED", I am guessing because of the SELECT FROM INSERTED.
How can I keep the SELECT deny, but allow the trigger to SELECT from the INSERTED pseudotable?
Thanks in advance!
Consider adding an EXECUTE AS clause so the trigger runs with the schema owner's permissions.
CREATE TRIGGER [dbo].[TR_Product_Update] ON [Product]
WITH EXECUTE AS OWNER
AFTER UPDATE
AS
SELECT ProductId
FROM INSERTED
Why did you deny select? What about just not granting select to them? There is a subtle difference between denying select and just not granting it to them. Also, if you denied select to any of the system level roles, then that would also probably be part of the problem.
--EDIT--
In the comments you asked whether or not SQL Server has context info. 2005 does and you can see how to use it here.
Session Variable – Context_Info: Session is a powerful tool in any of the programming language. SQL-Server is not a full fledge programming language but it do supports session variable for current session or connection. It stores value of session in 128 byte of binary information.
join to the inserted table instead something like:
update t1
set updated = getdate()
from table1 t1
join inserted i
on i.rowid = t1.rowid
This will probaly also perfom better than a subselect anyway.
I suspect your problem is that your UPDATE statement itself requires the SELECT permission.
I created a test database as follows:
DROP DATABASE triggerPermissionTest
CREATE DATABASE triggerPermissionTest
GO
USE triggerPermissionTest
GO
CREATE USER foo FROM LOGIN tester
GO
CREATE TABLE triggerTable (id int)
GO
DENY SELECT ON triggerTable to foo
GRANT UPDATE ON triggerTable to foo
GO
CREATE TRIGGER execAsTrigger ON triggerTable
AFTER UPDATE AS SELECT * FROM triggerTable
GO
INSERT INTO triggerTable VALUES (1)
GO
and tried the following Update statements with the 'tester' login:
UPDATE triggerTable SET id = 2
GO
UPDATE triggerTable SET id = id *2
GO
The first one executes fine and the trigger executes (providing the results of select * from triggerTable to the user without select permissions, demonstrating that it managed to do a select).
The second one gives me an error stating that I don't have select permission on triggerTable (because it needs to select from triggerTable in order to get the value of id to do the update).
This leads me to conclude that the trigger is incidental to the problem, and the UPDATE statement is the cause of the permission issue.