OPEN-FOR, varchar and nvarchar (more questions)

Question

hello
create or replace function fnEnumSystemUser
+(+
+FirstNameFilter nvarchar2,+
+...+
+)+
RETURN xxxxx.cursorType /* REF-CURSOR */
AS
+strSQL varchar(2000);+
SystemUserCursor   xxxxxcursorType;
BEGIN
+...+
+open SystemUserCursor FOR strSQL using FirstNameFilter;+
+...+
Notice that FirstNameFilter type = nvarchar2 and strSQL type=varchar - if "FirstNameFilter" contains Asian character, then I presume it'd become jibberish in "strSQL"? And also lost any unicode data in OPEN-FOR operation?
(Actually I don't know what exactly will happen, at least not until I test with the app which is not yet read. And you can't call the function with unicode character with TOAD and didnt manage to get around test this with SQL*Plus yet.)
Thanks

Answer 1

Presumption incorrect.
From the link given by hoek in your original post this morning:
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/datatypes.htm#sthref753
"You can interchange VARCHAR2 and NVARCHAR2 values in statements and expressions".
The NVARCHAR2 only really comes into things with table column datatypes for unicode data in non unicode character set.
If you're using a unicode character set (which you can find from info given in your third post), then you don't need to worry about NVARCHAR2 vs VARCHAR2 even when you're storing data.
If you use VARCHAR2 with multi-byte characters then you just need to make sure that you're using CHAR length semantics (NLS_LENGTH_SEMANTICS).
When you're fetching the data back into variables, you don't need to worry about VARCHAR2 and NVARCHAR2. As I already mentioned in previous threads, the datatype of the dynamically constructed query string passed into OPEN FOR has nothing to do with the datatypes returned by that query.
Going forward, if you do have issues with character set conversions and question marks then you need to look at character set conversions at the various touch points of your application, look at the NLS settings for the client(s) and server. Also the DUMP function is invaluable for seeing the bytes which are actually stored in a column / passed around.
From your first post, you gave the impression you were using bind variables for the parameters, this is good. For this sort of query building you might also want to look at SYS_CONTEXT for a slightly different way for binding your variables into your query string. There are a couple of useful asktom articles on this sort of thing.
So, in summary:
- you don't need to worry about using a NVARCHAR2 for the datatype of a PLSQL variable when just using that variable as a string for OPEN FOR
- if you are using a unicode character set, you don't need to worry about NVARCHAR2 vs VARCHAR2 for your column storage
- if you are using a non-unicode character set, you do need to worry about NVARCHAR2 vs VARCHAR2 for your column storage