I have a question about permission on the SQL server table. We have two SQL servers (sql-1, sql-2). The actual tables are on the sql-2, the synonyms to the actual tables are on sql-1 and the permission are set on sql-2.
I was not aware of this setup initially, so I took what I thought was a table on sql-1 at the time and did a INSERT into new table on sql-1, thinking I would inherit all the permissions. It did not. My question is when I was doing the Insert, even though the original table resides in sql-2, but when the insert is run on sql-1, would it not take the permission on sql-2 based on the synonym on sql-1 and apply it on the new table on sql-1?
The solution to my problem was to create the new table on sql-2, create the synonym on sql-1 pointing to sql-2 for the table, then set up the permission on sql-1 in the synonym itself on the new table in sql-2.
Related
I am using VS 2019 and comparing 2 databases using Schema Compare. Most of the time it finds the differences just fine and replicates them across. However, on some Stored Procedures it highlights a difference because of a schema name missing. e.g. [dbo]
Example:
Left Panel (local DB)
CREATE Procedure MyNewProcedure
(
#prmParam1 int
)
Select * from TableA where Id = #prmParam1
And on the Right hand Panel (remote DB) it shows the schema name correctly:
CREATE Procedure [dbo].[MyNewProcedure]
(
#prmParam1 int
)
Select * from TableA where Id = #prmParam1
If I run the update, it will create another version of this stored procedure but it won't belong to the dbo schema - it will take on the schema name of the connection.
It only does this for a handful of stored procedures. All the rest it adds the [dbo]. to each of the create statements.
I can not figure out why as I have to manually create the SP on the remote DB and then do an Exclude for each of these in the compare so it won't delete my new SP on the remote and create the new one without the [dbo].
Anyone got any ideas or seen this before?
I don't think I am creating the original SP (local) in any different way. Just a blank New Query window and type it in and hit F5.
Thanks in advance,
Ro
Here is the scenario for which Iam trying to create a SSIS package using VS2013. We have SQLServer2014 servers - A & B.
From ServerA.Database1, need to copy data for few specific tables to ServerB.Database2.
But before copy, have to drop the table and recreate the table at destination (ServerB.Database2) using the table schema from source (ServerA.Database1) because of schema changes happening frequently. Need to schedule this weekly.
How to accomplish using SSIS (how to retrieve source table schema information in the ssis package so that it will be used to create a table at the destination) ? or any other way ?
Thanks
Bhanu.
Add an execute sql task and provide sql text 'Drop table tablename' and then create table tablename (variables and datatypes)
Below approach will require a Linked Server. No need to worry about table schema.
Drop table TargetServer.database.dbo.tablename
Insert * into TargetServer.database.dbo.tablename from SourceServer.database.dbo.tablename
We have a requirement to provide customer access to a staging database so that they can extract their data into their own servers, but every table contains all customers data. All of the tables have a 'CustomerID' column. Customers should only see rows where the customerID is the same as theirs.
I am not looking for suggestions to create separate databases or views for each customer as both suggestions are high maintenance and low efficiency.
My solution has to work with:
100GB database
400 Tables
Updates every 30 minutes from the core transaction database
Quarterly schema changes (Application is in continuous Development).
Can anyone give me a definitive answer as to why the following method is not secure or will not work?:
I've set up a database user for each customer, with their customerID as an extended property.
I've created a view of every table that dynamically selects * from the table where the customerID column is the same as the extended property CustomerID of the logged in user. The code looks like this and appears to work well:
CREATE VIEW [CustomerAccessDatabase].[vw_Sales]
AS SELECT * FROM [CustomerAccessDatabase].[Sales]
WHERE [Sales].[CustomerID]=
(SELECT CONVERT(INT,p.value) AS [Value]
FROM sys.extended_properties
JOIN sys.sysusers ON extended_properties.major_id=sysusers.[uid]
AND extended_properties.name = 'CustomerID'
AND sysusers.[SID]=(SELECT suser_sid())
);
GO
To provide access to the views I've created a generic database role 'Customer_Access_Role'. This role has access granted to all of the table views, but access to the database tables themselves is denied.
To prevent users from changing their own customerID I've denied access to the extended properties like so:
USE [master];
GO
DENY EXEC ON sys.sp_addextendedproperty to [public];
GO
DENY EXEC ON sys.sp_dropextendedproperty to [public];
GO
DENY EXEC ON sys.sp_updateextendedproperty to [public];
GO
The end result is that I only need one database, and one set of permissions.
To add a new customer all I would need to do is create a new user with their customerID as an extended attribute and add them to the Customer_Access_Role. Thats it!
I am going to reiterate what everyone is stating already and sum it up.
You are making your job harder than it has to be.
Create a View, that is just their data and then give them Security access to that View.
Alternatively, extract all their data out of the "Core" database and into their own and give them the necessary access to that data.
We have a database a that is replicated to a subscriber db b (used for SSRS reporting) every night at 2.45 AM.
We need to add a column to one of the replicated tables since it's source file in our iSeries is having a column added that we need to use in our SSRS reporting db.
I understand (from Making Schema Changes on Publication Databases) and the answer here from Damien_The_Unbeliever) that there is a default setting in SQL Server Replication whereby if we use a T-SQL ALTER TABLE DDL statement to add the new column to our table BUPF in the PION database, the change will automatically propagate to the subscriber db.
How can I check the replication of schema changes setting to ensure that we will have no issues with the replication following making the change?
Or should I just run ALTER TABLE BUPF ADD Column BUPCAT Char(5) NULL?
To add a new column to a table and include it in an existing publication, you'll need to use ALTER TABLE < Table > ADD < Column > syntax at the publisher. By default the schema change will be propagated to subscribers, publication property #replicate_ddl must be set to true.
You can verify if #replicate_ddl is set to true by executing sp_helppublication and inspecting the #replicate_ddl value. Likewise, you can set #replicate_ddl to true by using sp_changepublication.
See Making Schema Changes on Publication Databases for more information.
I am using a SQL Server database with SQL Server Management Studio where I have existing tables. I add a few tables to it and it works just fine. However, for subsequent operations such as
Drop table XXX --OR
Create Trigger YYY on XXX
I run into a error statement that reads:
i) Cannot drop table XXX as it does not exist or you do not have permissions
ii) The object 'XXX' does not exist or is invalid for this operation
I tried to carry out an Insert operation but that showed me a similar error (The object 'XXX' does not exist). I can see this maybe a permissions issue since I am using an existing database. However, in that case, I should have been unable to create a table as well?
Can anyone pinpoint how I can work myself around this and what the problem is?
What is your default schema?
SELECT name, default_schema_name
FROM sys.database_principals
WHERE type = 'S';
Try qualifying your references to the table as SchemaName.XXX and see if that helps.
Most of times when I had similar situations tables were created in system databases (master, tempdb..). Of course it was my mistake.
So maybe try to search for a tables in other databases?