I've a SQL script with some special chars, the original encoding is WE8MSWIN1252, inside one script I have this char 'Ç'. When I execute a script with this char, my Oracle database encoding is AL32UTF8, if the client encoding is AL32UTF8 I will get a wrong char in database.
With this process, I need to adapt the environment variable each time I need to compile this script.
I'm looking for a more flexible approach, I want to have environment variable and the database set to AL32UTF8, and then adapt/convert the file from ANSI to UTF8. But I can't executed the script having the correct char in the database.
Do you know how can I do this, or configure something that is flexible to execute script with different special chars without changing the environment variable?
Thanks,
You can do this all in command line or but it into a single BAT file.
Would be like this:
C:\>chcp 1252
Active Codepage: 1252.
C:\>set NLS_LANG=.WE8MSWIN1252
C:\>sqlplus user/pwd#db #<your_sql_script_in_ANSI_encoding.sql>
C:\>exit
NLS_LANG is WE8MSWIN1252 only while you command line window is open.
Related
I have a SQL script that contains the following statement:
insert into employee(fname,lname) values('Jörg','Müller');
My Database Charset ist set to AL32UTF8 but when I execute the script in SQLPlus the german letters Ö and Ü are not saved correctly. How can I set the Charset of SQLPlus to UTF-8?
Is it possible to set the SQL*Plus Charset to UTF-8 in my script file (the sql script file contains the command to set the charset to UTF-8)?
My runtime environment is Window but script should also be able to run on unix. My oracle version is 19c.
SQL*Plus inherits the character set from cmd window. You need to set encoding to UTF-8 and tell it Oracle. This is done by NLS_LANG parameter.
Try this:
chcp 65001
set NLS_LANG=.AL32UTF8
sqlplus ....
Of course, this works only if your sql-file is also saved as UTF-8. Otherwise you need to adapt character sets from above.
See OdbcConnection returning Chinese Characters as "?"
You would typically use the environment variable NLS_LANG and for example set it like this in windows: SET NLS_LANG=AMERICAN_AMERICA.AL32UTF8
I try to run from DOS sqlldr with SYS/PASS#
sqlldr.exe 'sys/PASS#orcl' control="D:/test/control_file.dat" log="D:/test/log.log"
And got this error
Oracle sqlldr ORA-28009:connection as SYS should be as SYSDBA or SYSOPER
Is anyone can tell me to specify SYSDBA or SYSOPER in command line above ?
You need to add AS SYSDBA to your connection string. Try this:
sqlldr.exe 'sys/PASS#orcl AS SYSDBA' control="D:/test/control_file.dat" log="D:/test/log.log"
P.S.
NOTE from documentation:
This example shows the entire connect string enclosed in quotation marks and backslashes. This is because the string, AS SYSDBA, contains a blank, a situation for which most operating systems require that the entire connect string be placed in quotation marks or marked as a literal by some method. Some operating systems also require that quotation marks on the command line be preceded by an escape character. In this example, backslashes are used as the escape character. If the backslashes were not present, the command line parser that SQL*Loader uses would not understand the quotation marks and would remove them.
See your Oracle operating system-specific documentation for information about special and reserved characters on your system.
I'm currently migrating AIX to Linux. The Oracle script contains a $ in the column name. While fetching through the shell script, I set the escape character to $, but it does not work. The query is like below:
Set escape $
Select c.logoff$time from temp c;
When run from shell script I'm getting "c.logoff invalid identifier".
How can I fix this?
This isn't an SQL*Plus (I assume that's your client) problem, so the set escape isn't doing anything - that's for escaping things SQL*Plus tries to interpret - see the docs.
This is a shell issue/feature. the $time part is being treated as a shell variable, and that doesn't exist, so the final table name doesn't have it. You can escape that at shell level, referring to \$time; e.g. if you're using a heredoc:
sqlplus -s -l usr/pass#db <<EOF
select c.logoff\$time from temp c;
EOF
I some scripts I just echo some information to log program.
Unfortunately, although NLS_LANG = AMERICAN_AMERICA.UTF8 I am only able to display output with ASCII 7 bits.
sqlplus /nolog
host echo %NLS_LANG%
host echo "an OK test with ASCII 7 bit characters"
host echo "a KO test with accentuated characters : àéùôù"
Edit : it is a problem with unicode file (UTF-8)
You must set the codepage of your cmd window, since SQL*Plus inherits it.
Run chcp 65001 before you launch sqlplus.
However, there is an issue with UTF-8 on command line window, see how to use sqlplus with utf8 on windows command line: works [only] for characters [...] if the first character in a line is ASCII (code < 128, e.g. blank)
Perhaps Codepage 1252 also fulfill your needs:
chcp 1252
set NLS_LANG=.WE8MSWIN1252
sqlplus ...
I'm aware that the database engine itself is (often) on another machine and that SQL*Plus has no direct way of reading those environment variables, but I'm in a tricky situation where I merely need the environment variables from the machine the client itself is running on.
Is there a way to cheat these values into the SQL*Plus client from within a single script that will be run in SQL*Plus? The script consists of a single begin/end PL/SQL block, but if I need to use SQL*Plus directives of the set/define/variable sort that shouldn't be a problem either.
What I can't do is alter the way that the SQL*Plus executable itself is started (I don't have access to pass the values in as arguments).
Is there any way to accomplish this?
Note: dbms_system.get_env() seems to retrieve environment variables from the server itself, which is what I do not want.
You can get a few client-related things from the USERENV context, but not arbitrary environment variables.
If you can create a file on your local machine you could use the host command to set a substitution variable based on an environment variable:
SQL > host echo define homedir=$HOME > /tmp/gethome.sql
SQL > #/tmp/gethome.sql
SQL > host rm -f /tmp/gethome.sql
SQL > select '&homedir.' as home from dual;
HOME
------------
/home/apoole
1 row selected.
Not very pretty, but if you can't pass the variables on the command line as positional parameters then your options are rather limited.
This is using a Unix-y paths and commands of course, but you can do the same sort of thing in Windows.
Sys_context should solve your problem. You can set custom environment variable in database using DBMS_SESSION.SET_CONTEXT ('MY_NAMESPACE', 'MY_PARAMETER', v_input_parameter); and then fetch it using SYS_CONTEXT ('MY_NAMESPACE', 'MY_PARAMETER');
So you can run a initial pl/sql block to set variable in session and then use it as per requirement.
You can see an example here: http://blog.contractoracle.com/2010/03/using-dbmssessionsetcontext-to-store.html
If you could pass the variable via sqlplus argument passing mechanism. you could do the following,
cat > myscript.sql <<!
select '&1' as HOME from DUAL;
!
sqlplus user/pwd#db #myscript.sql $HOME