As per the link the parameter QUOTED_IDENTIFIERS_IGNORE_CASE can be set for a given session by including within the connection string.
Our application needs to use this setting and we require this to be set at Database/account level by default
Does Snowflake allow this setting to be done at account/database level?
With the ACCOUNTADMIN Role, you can set the this parameter at the account level with the following statement:
alter account set QUOTED_IDENTIFIERS_IGNORE_CASE = TRUE;
I would stress that you examine the warnings in the documentation you reference in the question closely.
Related
When I start the Kafka Connector I keep getting this error:
Caused by: org.apache.kafka.connect.runtime.rest.errors.BadRequestException: Connector configuration is invalid and contains the following 3 error(s):
snowflake.url.name: Cannot connect to Snowflake
snowflake.user.name: Cannot connect to Snowflake
snowflake.private.key: Cannot connect to Snowflake
I have tried setting url in following two ways:
snowflake.url.name=<ID assigned to me>.snowflakecomputing.com:443
snowflake.url.name=<My user id>.us-west-2.snowflakecomputing.com:443
I've set snowflake.user.name as:
snowflake.user.name=<My login id>
Not sure exactly how to set 'snowflake.private.key'. I copied contents of:
~/.ssh/id_rsa
After removing all new line characters so the value looks something like this:
snowflake.private.key=MIIEowIBAAKCAQEApM9bYyleCC+......... <long string>
I also tried to run the following command in Snowflake worksheet under SECURITYADMIN role but it keeps failing:
alter user <my user id> set rsa_public_key='MIIEowIBAAKCAQEApM9bYyleCC...';
Error message:
SQL access control error: Insufficient privileges to operate on user
What am I doing wrong?
In my case, it worked when I used the 'ACCOUNTADMIN' role.
snowflake.url.name should match the account name that you use to get to Snowflake via the UI, not your login name. This account name might have a region in the url, as well, which should be included. For example, xyzcompany.us-east-1.snowflakecomputing.com:443.
snowflake.url.name=<account_name>.snowflakecomputing.com:443
I would make sure that you are setting your role in the correct place in the UI worksheet. Easiest way to check is to run a SELECT CURRENT_ROLE(); command. You can also just run USE ROLE SECURITYADMIN; in the worksheet to make sure you are set correctly. That role should have permissions to alter user parameters.
In our web application we want to use DB2 row level access control to control who can view what. Each table would contain a column named userId which contain the user id. We want log-in users be able to see only row's usereId column with theirs id. I have seen db2 permission examples using DB2 session_id or user, for example taking DB2 given Banking example :
CREATE PERMISSION EXAMPLEBANKING.IN_TELLER_ROW_ACCESS
ON EXAMPLEBANKING.CUSTOMER FOR ROWS WHERE BRANCH in (
SELECT HOME_BRANCH FROM EXAMPLEBANKING.INTERNAL_INFO WHERE EMP_ID = SESSION_USER
)
ENFORCED FOR ALL ACCESS
ENABLE;
Our table gets updated dynamically hence we don't know what row get added or deleted hence we don't know what are all the user Id in the table.
At any given time, different user would log-on to the web to view information retrieve from the tables, the permission declaration above only take SESSION_USER as the input, can I change it to something like Java function parameter where one can pass arbitrary id to the permission? If not then how do I handle different log-in users at arbitrary time? Or do I just keep changing SESSION_USER dynamically as new user login (using "db2 set" ??)? If so then is this the best practice for this kind use case?
Thanks in advance.
Since the user ID in question is application-provided, not originating from the database, using SESSION_USER, which equals to the DB2 authorization ID, would not be appropriate. Instead you might use the CLIENT_USERID variable, as described here.
This might become a little tricky if you use connection pooling in your application, as the variable must be set each time after obtaining a connection from the pool and reset before returning it to the pool.
Check out Trusted Contexts, this is exactly why they exist. The linked article is fairly old (you can use trusted contexts with PHP, ruby, etc. now).
I'm trying to understand how to configure my Hibernate to work properly with my MSSQL DB and its schemas.
The problem is that during validation of tables, it logs (for every table):
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
- HHH000262: Table not found SHARED_CONFIGURATION
I debugged Hibernate to find out what causes this and found that it calls something like:
EXECUTE [mydb]..sp_columns N'SHARED_CONFIGURATION',N'',N'mydb'
Notice that 2nd parameter is schema name and there is passed empty string. When I tried to run this query against DB it returned empty result set. But when I passed 'dbo' as 2nd parameter the result set was not empty (meaning that Hibernate should call this instead).
OK so I was like it seems that I need to define schema. But both setting hibernate.default_schema or setting schema in #Table annotation on my entites threw exception:
Schema-validation: missing table [SHARED_CONFIGURATION]
So now I'm wondering what is the real problem. I also wanted to set default schema in my DB but was not allowed (Cannot alter the user 'sa', because it does not exist or you do not have permission.) even when executed with user 'sa' itself:
ALTER USER sa WITH DEFAULT_SCHEMA = dbo;
Note that this happens with any driver (JTDS, official MS driver..)
Can someone explain what is happening here and how "correctly" get rid of that warning message in log that says table does not exist even when it exists (and application is able to run properly with the database)?
I had the same problem and solved by setting the property hibernate.hbm2ddl.jdbc_metadata_extraction_strategy to individually
Setting up SQLServer with XA Drivers contains a step where you must assign users to the role called "SqlJDBCXAUser"; this can be done using "sp_addrolemember" sproc and undone using the "sp_droprolemember".
Is there a way of checking whether a particular user has been assigned that role ?
Or (better): a way of just listing ALL users assigned to use the specific role here ?
You can use IS_MEMBER
See the manual here - http://msdn.microsoft.com/en-us/library/ms186271.aspx
To list members, use sp_helprolemember or see How to list role members in SQL Server 2008 R2
I am stuck in a rather strange problem with SQL Server 2005, which throws
"SET QUOTED IDENTIFIER should be on when inserting record"
(using as SP) to the particular table. This worked fine earlier but is throwing this error randomly.
I have verified the SP. We didn't manually specify SET QUOTED IDENTIFIER settings inside, so it must be ON by default.
Can someone clarify what could be the problem?
The table must be created with SET QUOTED IDENTIFIER ON right? I didn't check the table script yet.
I have observed that this problem only occur with the SPs doing insert or update on a date column (modifiedAt)... A sample value is '2009-08-10 06:43:59:447'..
Is there a problem with the values passed?
After a long struggle we were able to fix this problem. I just wanted to share the reason.
Our build team maintains a separate in-house tool to deploy scripts, which internally triggers the SQLCMD (shell) utility to execute T-SQL scripts in a db.
Here is the culprit: by default, QUOTED_IDENTIFIER is OFF when running in SQLCMD mode!
Every script run through this tool is created with QUOTED IDENTIFIER OFF. We are the only module which uses indexed views. All the remaining stories you know well in my previous posts :(
NOTE: I am going to vote everyone's post as useful.
Script the stored proc, ensure/change SET options, run the ALTER PROC to ensure SET QUOTED IDENTIFIER ON is set.
Why?
The setting of "SET QUOTED IDENTIFIER" is defined at creation time for stored procs and is always "ON" for tables. Source, BOL.
When a table is created, the QUOTED
IDENTIFIER option is always stored as
ON in the table's metadata even if the
option is set to OFF when the table is
created.
When a stored procedure is created,
the SET QUOTED_IDENTIFIER and SET
ANSI_NULLS settings are captured and
used for subsequent invocations of
that stored procedure.
The default for connections can be defined at the server level (sp_configure 'user options') or database level (ALTER DATABASE). For SSMS, it's under "Tools..Options.. Query Execution..SQL Server..ANSI". It's also the default for client libraries too (except DB-LIb).
Now, it you open an SSMS Query Window and start typing "CREATE PROC.." then it uses SSMS settings when you run the code.
And SET QUOTED IDENTIFIER can not be set at run time inside the stored proc. Show me the a reference before you disagree... From the MS BOL link above:
When executed inside a stored
procedure, the setting of SET
QUOTED_IDENTIFIER is not changed.
You have to work hard to run any code with this OFF... so the most likely fix is to ALTER or re-create the stored proc.
I was just reading this article by Erland Sommarskog, The Curse and Blessings of Dynamic SQL, and it includes the following paragraph in regards to the SET QUOTED IDENTIFIER setting:
The default for this
setting depends on context, but the
preferred setting is ON, and it must
be ON in order to use XQuery, indexed
views and indexes on computed columns.
Does your stored procedure make use of XQuery, indexed views or indexes on computed columns at all?
In SQL Server 2005, SET QUOTED IDENTIFIER is OFF by default, not ON (unless using an ODBC or OLE connection...see this for more information).
You do not need to create the table with SET QUOTED IDENTIFIER ON to use it.
All you need to do is add SET QUOTED IDENTIFIER ON to the beginning of your SP to enable it for the run of the procedure (and make sure that if you don't wish to leave it on, you have SET QUOTED IDENTIFIER OFF to switch it back).
EDIT
I stand corrected. According to this MSDN Page, SET QUOTED IDENTIFIER is ON by default (unless connection with a DB-Library application.