Variable can contain some sensitive data
The set operation for the variable is visible in the query history for anybody with proper access right.
Is it possible to somehow mask the real value?
P.S. I've tried to use decrypt/encrypt - it's work for select as promised but not for a set.
If you need to secure queries, you need to upgrade the version and move to a business-critical edition.
Alternatively (though not a scalable solution), write a secure UDF with hardcoded value and call that UDF from your set operation. Nobody can see the secure UDF content and in the query, you will have only UDF call.
Hope this helps.
Related
Our company is setting up a new Snowflake instance, and we are attempting to migrate some processing currently being done is MS SQL Server. I need to migrate a Table-Valued SQL Function into snowflake. The source function has procedural logic in it, which is not allowed to my knowledge in snowflake UDTFs. I have been searching for a workaround with no success.
To be as specific as I can, I need a function that will take a string for input, decode that string, and return a table with the keys and their corresponding values. I cannot condense all of the logic to split the string and decode the keys into one SQL statement, so Snowflake SQL UDTFs will not work.
I looked into whether a UDTF can call a procedure and somehow I could simply return a result, but it does not look like that will work. Please let me know if there is any way to work around this.
I think Javascript UDTF is what you're looking for in Snowflake:
https://docs.snowflake.com/en/sql-reference/udf-js-table-functions.html
funny I just stumbled onto this as I'm running into the same thing myself. I found there is a SPLIT_TO_TABLE function that may be able to accomplish this. As Greg suggested nesting this together in the form of a CTE combined with a JOIN may allow you to accomplish what you need to do.
I am trying to execute (call) a SQL Server stored procedure from Infa Developer, I created a mapping (new mapping from SQL Query). I am trying to pass it runtime variables from the previous mapping task in order to log these to a SQL Server table (the stored procedure does an INSERT). It generated the following T-SQL query:
?RETURN_VALUE? = call usp_TempTestInsertINFARunTimeParams (?Workflow_Name?, ?Instance_Id?, ?StartTime?, ?EndTime?, ?SourceRows?, ?TargetRows?)
However, it does not validate, the validation log states 'the mapping must have a source' and '... must have a target'. I have a feeling I'm doing this completely wrong. And: this is not Power Center (no sessions, as far as I can tell).
Any help is appreciated! Thanks
Now with the comments I can confirm and answer your question:
Yes, Soure and Target transformations in Informatica are mandatory elements of the mapping. It will not be a valid mapping without them. Let me try to explain a bit more.
The whole concept of ETL tool is to Extract data from the Source, do all the needed Transformations outside the database and Load the data to required Target. It is possible - and quite often necessary - to invoke Stored Procedures before or after the data load. Sometimes even use the exisitng Stored Procedures as part of the dataload. However, from ETL perspective, this is the additional feature. ETL tool - here Informatica being a perfect example - is not meant to be a tool for invoking SPs. This reminds me a question any T-SQL developer asks with his first PL-SQL query: what in the world is this DUAL? Why do I need 'from dual' if I just want to do some calculation like SELECT 123*456? That is the theory.
Now in real world it happens quite often that you NEED to invoke a stored procedure. And that it is the ONLY thing you need to do. Then you do use the DUAL ;) Which in PowerCenter world means you use DUAL as the Source (or actually any table you know that exists in the source system), you put 1=2 in the Source Filter property (or put the Filter Transforation in the mapping with FALSE as the condition), link just one port with the target. Next, you put the Stored Procedure call as Pre- or Post-SQL property on your source or target - depending on where you actually want to run it.
Odd? Well - the odd part is where you want to use the ETL tool as a trigger, not the ETL tool ;)
I'm using ADO in a JScript (Microsoft JavaScript dialect) Windows Scripting Host script to update a SQL Server table. I'd like to get the number of rows affected by the update in the script, but JavaScript doesn't have pass-by-reference and so I can't do the usual thing where I receive the records affected from the Command#Execute function's RecordsAffected argument. So I'm looking for the best way to get that info.
For reasons not related directly to this query, I want to avoid using a stored procedure for this although I realize that that would work (I'd just return ##rowcount out of the SP). I'm trying to find a reliable but simple non-SP means of doing it.
I looked around and found this syntax for the statement:
UPDATE MyTable
SET MyColumn = (blah blah blah)
WHERE (blah blah blah) ;
SELECT ##rowcount as 'RowsAffected'
...which sends me back a one-row ResultSet containing the count. That does seem to work, and in my limited testing seems to work correctly (I don't get the wrong count when other operations are also happening, etc.), but it seems...kludgy for some reason.
Is that the best way to do it, given the perhaps-unreasonable constraints I've listed? Cross-platform solutions are not required (welcome, though, as always), it can be Microsoft SQL Server-specific (2005+).
Thanks in advance.
Not sure why you think it's kludgy. Nothing wrong with this approach.
I need to have a way to iterate through a database table without actually storing it in memory anywhere. I want to essentially read through the rows like an input iterator.
I've tried using cursors with a select statement (select * from table_name), but this retrieves the entire table and feeds it back to be one row at a time. So this solution is no good. Instead, I need it to only feed me each row as I ask for it.
Any suggestions are greatly appreciated.
Thanks!
You'll just want to use a forward only cursor. Your DB will need to support this. For detials, see MSDN's How to: Use Cursors.
If you're using SQL Server, you can use a Fast Forward-Only Cursor, which provides extra benefits.
When using multivalue parameters in sql reporting services is it more appropriate to implement the list filter using a filter on the dataset itself, the data region control or change the actual query that drives the dataset?
SSRS will support any scenario, so then I ask, is there a reason beyond the obvious of why this should be done at one level over another?
It makes sense to me that modifying the query itself and asking the RDBMS to handle the filtering would be most efficient but maybe I am missing something with respect to how the SSRS Data Processing Extension may handle this scenario?
You are correct. The way to go is to pass the parameters through to the database engine.
Reporting Services should only be ideally used to render content. The less data that you need to pass back to the client web browser, the faster the report will render.
You may find my answer to a similar post regarding using mulit-value parameters to be of use.
Passing multiple values for a single parameter in Reporting Services
Hope this helps but please feel free to pose any further questions you may have.
Cheers,
John
Using table-valued UDF is a good approach, but there is still one issue - in case if this function is called in many places of query, and even inside inner select, there can be performance problem. You can resolve this issue using table variable (or temp table eather):
DECLARE #Param (Value INT)
INSERT INTO #Param (Value)
SELECT Param FROM dbo.fn_MVParam(#sParameterString,',')
...
where someColumn IN(SELECT Value FROM #Param)
so function will be called only once.
Othe thing, if you don't use stored procedure, but embedded SQL query instead, you can just put MVP into query:
...
where someColumn IN(#Param)
...
Use the RDBMS to do the main filtering
SSRS provides filtering for the purposes on data driven display and/or dynamic display. Especially useful for sub reports etc