Cannot select from replication database view - snowflake-cloud-data-platform

My org has 2 snowflake accounts in different regions. Let's name them a (primary) and b (secondary). The Org admin enabled replication from account org.a => org.b. The account admin on a created a database called stuff_to_share and enabled replication to account org.b. He also created a schema all and a view called snapshot which is pulling the data from a Database called all.
create database stuff_to_share;
create schema all;
create view snapshot as
select * from all.fact.snapshot
On my side, I've created a DB from the replication
create database stuff_to_share as
replica of org.a.stuff_to_share;
I can see the view, I can run desc view stuff_to_share.all.snapshot but when I try to run a select I get an SQL Compilation Error like below:
I've found this article but cannot understand the recommendations. It says to
Avoid using the fully qualified name for the secure View in the Primary database.
How am I supposed to get data from a different DB in a view then?
Use the same name as that of the Primary database when creating the Secondary database.
I'm guessing this refers to stuff_to_share which is the same on both accounts.
Please help.

Related

Does creating a synonym automatically grant select access on underlying table in oracle

I have two users - schema1 and schema 2 in our oracle database.
I created a table and synonym in schema1 as follows
Create table test ( user varchar2(25)) ;
Create or replace synonym schema2.test for schema1.test
I observed a difference in behavior while I was trying to query test table from schema2 between our development and production environments.
select * from test
in our development environment did not throw any error.
But when I ran same command in production ,I got insufficient privileages error for schema2. I had to explicitly give select grant on test table to schema2 in production.
Why this difference could have arised between dev and prod environments?
Does creating a synonym automatically grant select access to an underlying table in oracle?
No, it doesn't. From the documentation:
However synonyms are not a substitute for privileges on database objects. Appropriate privileges must be granted to a user before the user can use the synonym.
Assuming privileges on the table haven't been granted without you realising or remembering, directly or via a role (which you could check easily of course), it sounds like schema2 in your development environment has 'any' privileges - such as select any table - granted as a shortcut, probably for convenience. That could be directly, or via a role.
Again from the documentation
The READ ANY TABLE or SELECT ANY TABLE system privilege also allows you to select data from any table, materialized view, analytic view, or hierarchy, or the base table of any materialized view, analytic view, or hierarchy.
Those sorts of privileges shouldn't be granted lightly, so it wouldn't be surprising for them not to be there in production. If they must be there in development - and someone must have agreed that - then an intermediate test or model environment which has the same restrictions as production would be useful to identify discrepancies, such as missing grants, before you try to deploy to production.

How to create a local schema in Oracle database 11g?

I have installed Oracle Database 11g Release 2 (11.2.0.1.0) for Microsoft Windows (x64). How do I create a new schema or local schema?
A schema is the collection of objects owned by a user.
So connect as a power user like SYSTEM and run a create user command. Find out more.
Once you have a user you can connect to it and create tables and other objects.
Have you tried looking in the docs? https://docs.oracle.com/cd/E11882_01/server.112/e41084/statements_6014.htm#SQLRF01313
In oracle a 'schema' is nothing more than the collection of objects belonging to a given user. Many people will even argue that a "user" is a "schema". I believe that it was with 11g (now out of support) that oracle introduced the CREATE SCHEMA command. That command simply combines creating a user and creating some tables belonging to that user into a single SQL statement. You can always do it the "old fashioned" way by simply issuing a CREATE USER, then issuing whatever CREATE . statements you need:
create user fubar identified by fubar;
create table fubar.mytable (dob date);
create view fubar.myview as (select * from fubar.mytable);
etc. etc.

Enable views for user in sql server 2016

I have a user in my SQL server who shall only be able to select from views in a certain schema.
However the database does not appear in the tree folder, and hence not the Views folder.
Is there a way to enable the display of these in the tree structure without granting access to the DB itself?
CREATE SCHEMA [gib]
GO
CREATE USER [GibUser] FOR LOGIN [GibUser] WITH DEFAULT_SCHEMA=[gib]
GO
CREATE VIEW [gib].[MyLocalData]
AS
SELECT TOP 10 * FROM DBData
GO
GRANT select on [gib].[MyLocalData] TO GibUser

How do I recreate a user/login on a SQL Azure Active Geo-Replication Secondary

I have a Premium P2 SQL Azure Database for my Production App, and for security reasons I've created DB Specific Schemas/Views/Roles and a specific DB User account for reading the Data from SSRS Queries.
Lets just call the server PRIMARY and my database MyApp
The setup script for this is below.
-- On Primary Master
CREATE LOGIN ssrsuser WITH password='******'
-- On Primary MyApp
CREATE USER ssrsuser FOR LOGIN ssrsuser
CREATE ROLE [ssrsreader] AUTHORIZATION [db_owner]
GRANT SELECT ON SCHEMA :: [App] TO [ssrsreader]
GRANT SELECT ON SCHEMA :: [Reports] TO [ssrsreader]
EXEC sp_addrolemember 'ssrsreader', 'ssrsuser'
So our users were putting a LOT of load on the Prod DB and we decided it was time to move the reporting functions off to a secondary sync'd slave database.
Since we're using the SQL Azure Premium Tier, we can enable Active Geo-Replication with a read-only secondary copy. In fact MS even say that it's suitable for read-only workloads such as reporting.
So I've setup the SECONDARY server, enabled the seeding, it's now complete and I can access the readonly copy using the SECONDARY admin user and password.
But the SECONDARY server doesn't have a login for ssrsuser and I while I can create one in SECONDARY.master, I can't DROP RECREATE the user since the SECONDARY.MyApp database is in readonly mode.
Is there any otherway to get around this. I really don't want to have to put the SECONDARY server admin user & password into SSRS connection strings.
There is no need to regenerate SID for ssruser in the user database. It is already there as a result of replication. All you need to do is associate that SID with a LOGIN in the master in the secondary server. This article provides the details.
https://azure.microsoft.com/en-us/documentation/articles/sql-database-geo-replication-security-config/
I hope this helps.

MS Access: Permission problems with views

"I'll use an Access ADP" I said, "it's only a tiny project and I've got better things to do", I said, "I can build an interface really quickly in Access" I said.
</sarcasm>
Sorry for the rant, but it's Friday, I have a date in just under two hours, and I'm here late because this just isn't working - so, in despair, I turn to SO for help.
Access ADP front-end, linked to a SQL Server 2008 database
Using a SQL Server account to log into the database (for testing); this account is a member of the role, "Api"; this role has SELECT, EXECUTE, INSERT, UPDATE, DELETE access to the "Api" schema
The "Api" schema is owned by "dbo"
All tables have a corresponding view in the Api schema: e.g. dbo.Customer --> Api.Customers
The rationale is that users don't have direct table access, but can deal with views as if they were tables
I can log into SQL using my test login, and it works fine: no access to the tables, but I can select, insert, update and delete from the Api views.
In Access, I see the views, I can open them, but whenever I try to insert or update, I get the following error:
The SELECT permission was denied on the object '[Table name which the view is using]', database '[database name]', schema 'dbo'
Crazy as it sounds, Access seems to be trying to access the underlying table rather than the view.
Any ideas?
Could it be because of this: "To update a partitioned view, the user must have INSERT, UPDATE, and DELETE permissions on the member tables."
http://msdn.microsoft.com/en-us/library/ms187956.aspx

Resources