I'm executing some random script to my local database and I have problem with non-english letters. When I'm executing the same insert statement directly from sql develeoper everything is ok. Could somebody explain my how can I avoid this problem using sql script?
Example. Everything works okay.
Statement: insert into my_table values ('aaaaała');
Result: 'aaaaała';
Now I'm pasting the same insert statement into my sql file(script.sql) and I'm wirting:
#'D:\script.sql';
'D:\' - it is location of that file
Statement: insert into my_table values ('aaaaała');
Result: 'aaaaała';
The result is wrong:
My settings:
You must set your NLS_LANG value according to the character set of the script.sql file. Typically you set this in the options in at the "Save" dialog.
For example if the .sql file was saved as UTF-8 then you must run:
set NLS_LANG=.AL32UTF8
sqlplus .... #'D:\script.sql';
See also OdbcConnection returning Chinese Characters as "?" for more details.
Related
I have to store some strange characters in my SQL Server DB which are used by an Epson Receipt Printer code page.
Using an INSERT statement, all are stored correctly except one - [SCI] (nchar(154)). I realise that this is a control character that isn't representable in a string, but the character is replaced by a '?' in the stored DB string, suggesting that it is being parsed (unsuccessfully) somewhere.
The collation of the database is LATIN1_GENERAL_CI_AS so it should be able to cope with it.
So, for example, if I run this INSERT:
INSERT INTO Table(col1) VALUES ('abc[SCI]123')
Where [SCI] is the character, a resulting SELECT query will return 'abc?123'.
However, if I use NCHAR(154), by directly inserting or by using a REPLACE command such as:
UPDATE Table SET col1 = REPLACE(col1, '?', NCHAR(154))
The character is stored correctly.
My question is, why? And how can I store it directly from an INSERT statement? The latter is preferable as I am writing from an existing application that produces the INSERT statement that I don't really want to have to change.
Thank you in advance for any information that may be useful.
When you write a literal string in SQL is is created as a VARCHAR unless you prefix is with N. This means if you include any Unicode characters, they will be removed. Instead write your INSERT statement like this:
INSERT INTO Table(col1) VALUES (N'abc[SCI]123')
I am trying to do a bulk insert of a .CSV from a remote location.
My SQL statement is:
BULK INSERT dbo.tblMaster
FROM '\\ZAJOHVAPFL20\20ZA0004\E\EDData\testbcp.csv'
WITH (FIELDTERMINATOR = ',',
ROWTERMINATOR = '\n')
My .CSV looks like this:
john,smith
jane,doe
The CSV is saved with UTF-8 encoding, and there is no blank line at the bottom of the file. The table that I am bulk inserting too is also empty.
The table has two columns; firstname (nvarchar(max)) and secondname (nvarchar(max)).
I have sysadmin rights on the server so have permission to perform bulk inserts.
When running the SQL, it runs without error, and simple shows -
0 row(s) affected
and doesn't insert any information.
Any help is greatly appreciated.
I know this may be too late to answer but I thought this might help anyone looking for the fix. I had similar issue with Bulk Insert but didn't find any fix online. Most probably the flat/csv file was generated with non-windows format. If you can open the file in Notepad++ then go to edit tab and change the EOL Conversion to "Windows Format". This fixed the problem for me.
Notepad++>> Edit >> EOL Conversion >> Windows Format
When you specify \n as a row terminator for bulk export, or implicitly use the default row terminator, it outputs a carriage return-line feed combination (CRLF) as the row terminator. If you want to output a line feed character only (LF) as the row terminator - as is typical on Unix and Linux computers - use hexadecimal notation to specify the LF row terminator. For example:
ROWTERMINATOR='0x0A'
no need to do the following:
Notepad++>> Edit >> EOL Conversion >> Windows Format
I opened the CSV with Excel and hit Control + S to resave it. That fixed the issue for me.
Try inserting the file using bcp.exe first, see if you get any row or any error. The problem with
BULK INSERT ...
FROM '\\REMOTE\SHARE\...'
is that you're now bringing impersonation and delegation security into picture and is more difficult to diagnose the issue. When you access a remote share like this you are actually doing a 'double-hop' Kerberos impersonation (aka. delegation) and you need special security set up. Read Bulk Insert and Kerberos for the details.
The problem is, at least in part, the UTF-8 encoding. That is not supported by default. If you are using SQL Server 2016 then you can specify Code Page 65001 (i.e. add , CODEPAGE = '65001' to the WITH clause). If using an earlier version of SQL Server, then you need to first convert the file encoding to UTF-16 Little Endian (known as "Unicode" in the Microsoft universe). That can be done either when saving the file or by some command line utility.
I need to grab data from some oracle database tables and format it into a fixed width text file.
I want to know if its possible to create a text file using sql.
I looked at some stuff and found the bc and xp_cmdshell but they are a bit confusing.
I am pretty new to sql and oracle databases.
Is this possible and how can I begin?
I don't need to open a file or check for existing file, overwriting is fine, what ever makes it easiest.
I don't need anything big or complex, a simple script to grab values and create a text file.
Just an update:
I don't think bcp works in the toad for oracle editor.
I found this tutorial here: http://www.sqlteam.com/article/exporting-data-programatically-with-bcp-and-xp_cmdshell
but the first bcp command does not compile, it says invalid sql query
If you are using the SQL*Plus client, you can spool to an output file. Here is a sample SQL*Plus file:
set serveroutput on size 1000000
set linesize 150
spool C:\path_to_file\filename.extension
-- Your SQL statement
select columns
from table
where somecondtion;
-- Your next SQL Statement
select ...
from ...;
spool off
I think you can use sqlplus command line tool todo this. See oracle manual for formatting hints.
I am unable to insert email id in the oracle 9i tables.
I am using putty.
INSERT INTO email(mail_list)values('sundar#abc.com');
I m getting the below error:
SQL> INSERT INTO email(mail_list)values('sundar#
abc.com');
SP2-0042: unknown command "abc.com')" - rest of line ignored.
Putty is not accepting # symbol.
I have read the below in one of the portal:
The problem is common with unix environment with the display terminal keyboard settings. The sqlplus session had trouble interpreting the "#" sign, because it was assigned in the terminal to the "kill" setting.
how to correct the issue?
Thanks
Sundar
Try to insert without having to use the # character. Find out the ascii value:
SQL>select ascii('#') from dual;
64
And then compose the email addres using the CHR function.
INSERT INTO email(mail_list)values('sundar'||chr(64)||'abc.com');
(I have no knowledge of Putty so I used my SQL knowledge).
Try with the below statement in SQL Server:
INSERT INTO tablename(email) VALUES('xyz#gmail.com')
I write:
CREATE TABLE Person (
name CHAR(10),
ssn INTEGER);
and save it to a file "a.sql".
If I then run it by typing "#a" in the SQL*Plus command prompt, it will tell me that the line starting with "ssn" is not recognized as a command, and is ignored.
From what I gather, it seems that sqlplus terminates a command if it encounters multiple newline characters in a row. Is this an accurate statement? If so, does anyone know if this is necessary/ why it chooses to do this?
I don't know about the why, but a completely blank line terminates a command in SQL*Plus.
Quote from the SQL*Plus docs :
Ending a SQL Command:
You can end a SQL command in one of three ways:
with a semicolon (;)
with a slash (/) on a line by itself
with a blank line
You can also change how blank lines are treated with SET SQLBLANKLINES
SQLBL[ANKLINES] {ON|OFF}
Controls whether SQL*Plus allows blank lines within a SQL command or script. ON interprets blank lines and new lines as part of a SQL command or script. OFF, the default value, does not allow blank lines or new lines in a SQL command or script or script.
Enter the BLOCKTERMINATOR to stop SQL command entry without running the SQL command. Enter the SQLTERMINATOR character to stop SQL command entry and run the SQL statement.
By default, SQLPlus does terminate (but not execute) a statement when a blank line is entered. It has always done this. It probably seemed like a good idea in the days before screen editors and query tools.
You can change that default behaviour with
set SQLBLANKLINES on
In which case you'd have to enter a line with just a full stop to terminate (but not execute) a statement.
But if you are wanting to insert multiline text in a varchar2 or a clob field, you may use
chr(10)
insert into t values ('Hello,'||chr(10)||chr(10)||' How are you?');
insert into t values (
'Hello,
How are you');
will not work for reasons explained above.