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')
Related
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.
I'm using SQL Server and I'm in the need of passing unique identifiers to my client.To avoid the usage of UUID's I want to use a sequence. In order to do so I took a look at the MS docs and found this example.
USE MyDB;
GO
CREATE SCHEMA Test;
GO
CREATE SEQUENCE Test.CountBy1
START WITH 1
INCREMENT BY 1 ;
GO
SELECT NEXT VALUE FOR Test.CountBy1 AS FirstUse;
SELECT NEXT VALUE FOR Test.CountBy1 AS SecondUse;
Which fails for me. I'm currently using sequences at another service in my application where they work - but they are used as a default value. The syntax here differs since I want to select the sequence as integer and pass it to my Java server and from there via REST to a web client.
The example was copied as it is from Microsofts docs. Only the database name was adjusted. Example B from that page is working.
mssql-server mssql-tools are running on a Ubuntu 16.04 host.
Error message:
[2017-07-11 16:38:24] [S00016][217] Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 2).
[2017-07-11 16:38:24] The connection is closed.
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.
Im trying to run the following to import a large volume of sales data in a text file into a database. When i run the following i get the error: "Invalid object name 'PetDatabase.Sales'
BULK INSERT PetDatabase.Sales
FROM 'C:\Temp\P1.txt'
WITH
(
FORMATFILE = 'C:\Temp\PetSales.Fmt'
);
Can anyone see whats causing my problem? I do have the tables within a folder; however, when i tried PetsDatabase.Tables.Sales it made no difference.
Ignore this answer. It was written when the question was tagged with mysql. Leaving the answer here to keep the comments.
--
Try using LOAD DATA INFILE instead.
http://dev.mysql.com/doc/refman/5.1/en/load-data.html
Make sure PetDatabase.Sales exists in your text file.
Swap for whichever row and field terminator delimiters you're using. Here I'm using delimiters from a comma separated file
BULK INSERT PetDatabase
FROM 'c:\temp\p1.txt'
WITH
(
FIELDTERMINATOR = ',',
ROWTERMINATOR = '\n'
)
GO
--Check the content of the table.
SELECT *
FROM PetDatabase
GO
--Drop the table to clean up database.
SELECT *
FROM PetDatabase
GO
Also, make sure the following doesn't apply to you:
If a SQL Server user is logged in using Windows Authentication, the user can read only the files accessible to the user account, independent of the security profile of the SQL Server process.
When executing the BULK INSERT statement by using sqlcmd or osql, from one computer, inserting data into SQL Server on a second computer, and specifying a data_file on third computer by using a UNC path, you may receive a 4861 error.
To resolve this error, use SQL Server Authentication and specify a SQL Server login that uses the security profile of the SQL Server process account, or configure Windows to enable security account delegation.
Is PetDatabase is schema name or database name?
If it is database name, then include schema name also like this if your schema name is dbo.
PetDatabase.dbo.Sales
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.