I have a session variable in the RPD of OBIEE 12c and I wanted to put a small sql code in it as default initializer. It's something that selects only one row but this gives a syntax error (the sql is correct, I've tested it). Is this possible? Or are there any other ways to make the default dynamic?
There is also one other thing: I only have the category constants in my tab 'category' of the expression builder.
You can't use SQL to set your default initializer, that's why you only see Constants as an option. It's meant to be a constant value. The initialization block is used to set your session variable to a dynamic value.
https://docs.oracle.com/cd/E28280_01/bi.1111/e10540/variables.htm#BIEMG3104
You want the content of the variable to be a SQL statement as a string?
Like VALUEOF(NQ_SESSION.MYVAR) = 'select ''This is jist some text'' from dual;"?
Cause that's what you then get. Text. Uninterpreted. Like typing a sentence, not code.
Related
I am using PLSQL developer to work with oracle db. When I compile a view which stores code like this:
select 'xidmət' as service from dual
the 'ə' character in the string becomes '?' character.
I think it's some oracle or plsql developer configuration problem, but I don't know what.What do you think the problem is?
First, check what your character set is using this:
select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
Then set your NLS_LANG environment variable to AMERICAN_AMERICA.CHARSET where CHARSET is the value found with that select. If you are in Windows, you will have to go to Control Panel, System, Advanced, Environment Variables, and set NLS_LANG under System variables.
Oracle does at least a 'one-pass' conversion between client and database, but the problem is that there are so many layers between client and database, including your client software, that it is usually better to match your client NLS_LANG with the database setting.
It also depends how that character was inserted. It might have been inserted using a different client tool using a different NLS_LANG, so you might have to update your extended ASCII characters (or foreign characters) before you get a consistent view from your select.
Need to configure your systems NLS_LANG parameter, according to your language preferences. Here's a link:
http://www.nazmulhuda.info/setting-nls_lang-environment-variable-for-windows-and-unix-for-oracle-database
For example, we have letters like "ąčęėįšųū". So in order to see them in pl/sql, we set NLS_LANG with value "LITHUANIAN_LITHUANIA.BLT8MSWIN1257".
Hope it helps. Good luck.
i have a DB which has a table named LIKE.
uppon trying to execute any query on the table, it gives me an error and i know it's because of the name which is trying to use the query keyword LIKE.
Now, i have "bypassed" this issue in MySQL by just selecting the table as
SELECT tk_oseba_id, COUNT(tk_tip_like_id) AS St_Like_haha
FROM student999.`like`;
Now this same line wont work at `l...is there any special way to to this in oracle or how can i manipulate with the table by not using the LIKE keyword.
Oracles's counter part to mysql's back tick is quote for defining tablenames/columns.
To use a key word as a table name though I recommend against it...
wrap the table name in quotes. From student9999."like"
AND... it forces case sensitivity when you use the quotes!
The repository in OBIEE 11g is a prebuilt RPD from oracle OBIApps. The connection pool is appropriate and is working.
But while updating the row count there are few variables which pop up and as they are default so i press them "OK".
But then there is an error message which is stated as
nQSError23006:The session variable, NQ_SESSION.USER_LANGUAGE_CODE, has no value
Then I tried to disable the session variable by disabling initialization block.
Then also the same error is popping up.
Please guide me with this error.
That means the variable is (re-)used as a reference in - for example - other initialization block SQLs, calculations or generally inside other repository objects and is still being queried. Or at least "attempted to be queried".
Best search across your RPD for references to that variable.
The Variable was being pointed from the Standard Views by oracle where in the the view was written with a where clause.
Where Clause was as follows:
select * from xyz where language_code = 'NQ_SESSION.USER_LANGUAGE_CODE'.
I'm trying to convert some Informix ESQL to Oracle Pro*C. In the existing Informix code the "SERIAL" data type was used to indicate automatically incrementing columns. According to the Oracle documentation, the Oracle Migration Workbench for Informix should be able to handle this, and it explains that it converts the "SERIAL" data type into a "NUMBER" with an associated Oracle sequence and trigger. However, when trying to run the tool it simply replaces the word "SERIAL" with "ERROR(SERIAL)", so I've been trying to manually add in the trigger/sequence.
Their example here: http://docs.oracle.com/html/B16022_01/ch2.htm#sthref112 shows a way that this can be done. The sequence appears to be fairly straight forward, however when trying to create a trigger like so:
CREATE TRIGGER clerk.TR_SEQ_11_1
BEFORE INSERT ON clerk.JOBS FOR EACH ROW
BEGIN
SELECT clerk.SEQ_11_1.nextval INTO :new.JOB_ID FROM dual; END;
The Pro*C preprocessor picks up the "CREATE" keyword here, and decides that I'm not allowed to use the host variable ":new.JOB_ID", because host variables cannot be used in conjunction with "CREATE" statements.
My question is, is there some way to create a trigger that links an Oracle sequence to a particular column without using a host variable to specify the column name? The Oracle documentation seems to indicate that their migration tool should be able to cope, which means there must be some way of doing this. However all the examples of the trigger use that I have found all use the host variable which causes the preprocessor to complain.
Thank you for your time.
(Note: I've used the trigger/sequence/column names from the example in the Oracle documentation in the example above.)
I managed to resolve the issue by using an "EXEC SQL EXECUTE IMMEDIATE" statement.
char sql_buf[4096+1];
snprintf(sql_buf, 4096, <sql>);
EXEC SQL IMMEDIATE :sql_buf;
This bypasses the preprocessor and therefore allows the statement through without complaint.
It is impossible to create a trigger that links an Oracle sequence to a particular column without using a "host variable" to specify the column name. By the way it isn't "host variable" - just reference. The same trigger may fire on update and insert for example, so you have to specify what you are referencing: new or old variables. You can do it in MS-SQL but not in Oracle.
When trying to enter a SQL query with parameters using the Oracle OLE DB provider I get the following error:
Parameters cannot be extracted from the SQL command. The provider might not help to parse parameter information from the command. In that case, use the "SQL command from variable" access mode, in which the entire SQL command is stored in a variable.
ADDITIONAL INFORMATION:
Provider cannot derive parameter information and SetParameterInfo has not been called. (Microsoft OLE DB Provider for Oracle)
I have tried following the suggestion here but don't quite understand what is required:Parameterized queries against Oracle
Any ideas?
To expand on the link given in the question:
Create a package variable
Double click on the package variable name. (This allows you to access the properties of the variable)
Set the property 'EvaluateAsExpression' to true
Enter the query in the expression builder.
Set the OLE DB source query to SQL Command from Variable
The expression builder can dynamically create expressions using variable to create 'parametised queries'.
So the following 'normal' query:
select * from book where book.BOOK_ID = ?
Can be written in the expression builder as:
"select * from book where book.BOOK_ID = " + #[User::BookID]
You can then do null handling and data conversion using the expression builder.
If You use Data Flow Task and use OLE DB Source, and you need parameterize your Query :
Create Variable to save "Full" of Query statement : Right Click on blank area outside the package - and Click Variables :
Click Add Variables on Variables Window :
Make the name is SQL_DTFLOW_FULL or something that can you understand easily. The variable data type is STRING
Create Variable(s) to save your parameter(s).
i.e, the full of Query stamements is :
SELECT * FROM BOOK WHERE BOOK_ID = #BookID --#BookID is SQL Parameter
at the sample above, I have just one parameter : #BookID, so I need to create one variable to save my parameter. Add more variables depends on your Queries.
Give it name SQL_DTFLOW_BOOKID
The variable data type is STRING
So, you need make your SSIS neat, and the variables is sorted in understandable parts.
Try to make the variable name is SQL_{TASK NAME}_{VariableName}
Make Expression for SQL_DTFLOW_FULL variable, click on number 1, and start fill number 2. Make Your SQL Statements to be a correct SQL Statement using string block. String block usually using "Double Quote" at the beginning and the end. Concat the variables with the string block.
Click evaluate Expression, to showing result, to make sure your query is correct, copy-paste the Query result at SSMS.
Make sure by yourself that the variables is free from SQL Injection using your own logic. (Use your developer instinct)
Open the Data Flow Task, open the OLE DB Source Editor by double click the item.
Select the Data Access Mode : SQL Command From Variable
Select the Variable Name : SQL_DTFLOW_FULL
Click Preview to make sure it works.
That is all, my way to prevent this SSIS failure case. Since I use this way, I never got that problem, you know, SSIS something is weird.
To change the variable value, set it before Data Flow Task, the SQL Result of SQL_DTFLOW_FULL variable will changed every you change your variable value.
In my case the issue was that i had comments within the sql in the normal form of /* */ and i also had column aliases as "Column name" instead of [Column Name].
Once i removed them it works.
Also try to have your parameter ? statement within the WHERE clause and not within the JOINS, that was part of the issue too.