INSERT multiple rows not working SQL Server 2008 R2 - sql-server-2008-r2

This seems like a silly question, but has been driving me crazy. The title pretty much says it: I cannot insert multiple rows into my table.
Here's the relevant code:
create table ##temp (
no1 int,
no2 int
)
insert into ##temp (no1,no2)
values
(1,2),
(3,4)
The error is
Incorrect syntax near ','
which is the comma between (1,2) and (3,4)
Hope somebody can help. I'm using SQL Server 2008 R2, by the way. Thanks..

Try this:
insert into ##temp (no1,no2)
select 1, 2
union select 3, 4

Related

Postgres Crosstab query - "duplicate category" error where 2 values have the first 62 characters in common

I'm a newbie working on a postgres 9.5 (dynamic) crosstab query, that has been working fine in general, but I've come up with a peculiar issue with large nearly identical category names and I hope there's an easy solution/explanation.
Requires tablefunc:
CREATE EXTENSION IF NOT EXISTS tablefunc;
Schema:
CREATE TABLE temp_table (id integer, name text, data text);
INSERT INTO temp_table VALUES (1, 'ThisSentenceIsExactlySixtyTwoCharactersLongPlusNumbersAtTheEnd', 'data1');
INSERT INTO temp_table VALUES (2, 'ThisSentenceIsExactlySixtyTwoCharactersLongPlusNumbersAtTheEnd1', 'data2');
Query:
SELECT * FROM CROSSTAB($$SELECT id, name, data FROM temp_table ORDER BY 1,2$$ , $$SELECT DISTINCT name FROM temp_table$$) AS ct (row integer, col_1 text,col_2 text);
Instead of the result I expect, I get:
ERROR: duplicate category name SQL state: 42710
Can anyone please tell me what's going on here, and if there's a simple fix?
Thanks!
I'm guessing it has something to do with the fact that PostgreSQL truncates identifiers (including column names and category names) to 63 characters. Seems like there's an off-by-one error somewhere in crosstab as well maybe. Do your names need to be so long? That's probably the easiest fix. You could also try increasing NAMEDATALEN and recompiling postgres.
https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS

Numeric literals in sql server 2008

What is the type that sql server assigns to the numeric literal: 2. , i.e. 2 followed by a dot?
I was curious because:
select convert(varchar(50), 2.)
union all
select convert(varchar(50), 2.0)
returns:
2
2.0
which made me ask what's the difference between 2. and 2.0 type wise?
Sql server seems to assign types to numeric literals depending on the number itself by finding the minimal storage type that can hold the number. A value of 1222333 is stored as int while 1152921504606846975 is stored as big int.
thanks
Edit: I also want to add why this is so important. In sql server 2008 r2, select 2/5 returns 0 while select 2./5 returns 0.4, due to the way sql server treats these types. In oracle and Access select 2/5 (oracle: select 2/5 from dummy) returns 0.4. That's the way it should be. I wonder if they fixed this behaviour in sql server 2012. I would be surprised if they did.
This script might answer my question. The type of 2. is numeric(1, 0).
create table dbo.test_type (field sql_variant)
go
delete from dbo.test_type
go
INSERT INTO dbo.test_type
VALUES (2.);
INSERT INTO dbo.test_type
VALUES (2.0);
SELECT field
, sql_variant_property (field
, 'BaseType')
AS BaseType
, sql_variant_property (field
, 'Precision')
AS Precision
, sql_variant_property (field
, 'Scale')
AS Scale
FROM dbo.test_type
It returns:
2 numeric 1 0
2.0 numeric 2 1
This is why when 2.0 is converted to varchar the result is 2.0. Sql server seems to record the precision.

Extract portion of date string and convert to datetime in T-SQL

I'm running SQL Server Standard 2008 R2 on a 64 bit version of Windows Server 2008 R2 standard (sp1)
I've imported a log file as a flat file source. One of the columns from the import called col2 in the table called big holds values like this: 16/Mar/2007:11:30:17 as varchar(50).
I want to convert that column (col2) to a datetime datatype.
One method I was trying was to extract each part of the date string and then recombine and convert them.
The problem I ran into is that each column has different widths since the log file couldn't be neatly delimited, making using something like CHARINDEX return a single digit or sometimes NULL.
I've been attempting to set up using regex using CLR integration but can't get it to work (I can't create a C# project in Visual Studio, there's no option for it) and Master Data Services won't install because SQL Server 2008 R2 Standard doesn't support it.
What is my best method to do this? Using CASE, SUBSTRING and CHARINDEX?
Try this
DECLARE #d varchar(50) = '16/Mar/2007:11:30:17'
SELECT CAST(STUFF(#d,CHARINDEX(':',#d),1,' ') AS DATETIME)
Though I liked the idea of EricZ, however, here is my solution
DECLARE #d varchar(50) = '16/Mar/2007:11:30:17'
SELECT CAST( LEFT(#d,PATINDEX('%:%',#d) - 1) + ' ' + SUBSTRING(#d,PATINDEX('%:%',#d) + 1,LEN(#d)) AS DATETIME)
select convert(datetime,
SUBSTRING('16/Mar/2007:11:30:17', 0, CHARINDEX(':', '16/Mar/2007:11:30:17')) + ' ' +
SUBSTRING('16/Mar/2007:11:30:17', CHARINDEX(':', '16/Mar/2007:11:30:17') + 1, 8) , 1)
try this>
select convert(datetime,STUFF(big,CHARINDEX(':',big),1,' '),101) from yourtable
Example:Check here as datatime string format.If its the same it will work
DECLARE #d varchar(50) = '16/Mar/2007:11:30:17'
select convert(datetime,STUFF(#d,CHARINDEX(':',#d),1,' '),101)

SSRS 2005 passing parameters to SQL Server 2000 stored procedure

Below is code that I built from an example I found online, I can't find the link, but the code is referenced in the answers on this stack overflow question: Passing multiple values for a single parameter in Reporting Services.
Here is the SQL code I am working with right now within my stored procedure, it was a long procedure so I summed it down to just the section I am working on, and added the DECLARE and SET for #EMPLOYEES, which are passed as a parameter from SSRS to make the code snippet run.
DECLARE #EMPLOYEES varchar(8000)
-- EMPLOYEES is a comma separated list of EMPLOYEE IDS
-- FROM SSRS Report Parameters. Each ID is 12 characters
-- And there are 806 Employees to choose from, which
-- when all are selected, the Comma separated string grows
-- to 11,193 characters, much longer than 8000
SET #EMPLOYEES = 'EMP000000001,EMP000000002,EMP000000003'
CREATE TABLE #EMPLOYEEIDS
(
EMPLOYEEID varchar(100) NOT NULL
)
DECLARE #CharIndex AS int
DECLARE #Piece AS varchar(100)
-- FILL THE #EMPLOYEEIDS TABLE WITH THE COMMA SEPARATED EMPLOYEE IDS
SELECT #CharIndex = 1
WHILE #CharIndex > 0 AND LEN(#EMPLOYEES) > 0
BEGIN
SELECT #CharIndex = CHARINDEX(',', #EMPLOYEES)
IF #CharIndex > 0
SELECT #Piece = LEFT(#EMPLOYEES, #CharIndex - 1)
ELSE
SELECT #Piece = #EMPLOYEES
INSERT INTO #EMPLOYEEIDS (EMPLOYEEID) VALUES (#Piece)
SELECT #EMPLOYEES = RIGHT(#EMPLOYEES, LEN(#EMPLOYEES) - #CharIndex)
END
SELECT * FROM #EMPLOYEEIDS
DROP TABLE #EMPLOYEEIDS
I had 6 sets of multi-values, all of them worked fine, until I found that the reports were missing much of the data for employees, to which I found that the VARCHAR(8000) was overflowed when selecting all the employees on the report parameters (there are over 800 of them). The Report would run, SQL would happily truncate the VARCHAR to 8000 characters, and a quarter of the IDS were not parsed.
So I tried to switch the VARCHAR to a text field, and none of the parsing functions would work when the field is set up as TEXT. I get errors like the following:
Msg 8116, Level 16, State 2, Procedure usp_QualityMonitoring_AllProfiles_SelectWithParameters, Line 89
Argument data type text is invalid for argument 1 of left function.
This is understandable, I know that many functions that work with VARCHAR will not work with TEXT. So, SQL is truncating everything after 8000 characters when I use a VARCHAR, and the procedure won't ever run if I switch it to TEXT.
What other options to I have to pass multi-valued parameters from SSRS to a SQL Server stored procedure that can support this many options?
OR is there a way to fix the code in the stored procedure to parse through TEXT instead of VARCHAR?
Note: I originally thought the SQL Server running the Stored Proc was 2005, but I have determined that it is not:
SELECT ##VERSION
-- Microsoft SQL Server 2000 - 8.00.2039 (Intel X86) May 3 2005 23:18:38 Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

Dump file from Sqlite3 to PostgreSQL: why do I always get errors when import it?

I have many tables in Sqlite3 db and now I want to export it to PostgreSQL, but all the time I get errors.
I've used different techniques to dump from sqlite:
.mode csv
.header on
.out ddd.sql
select * from my_table
and
.mode insert
.out ddd.sql
select * from my_table
And when I try to import it through phppgadmin I get errors like this:
ERROR: column "1" of relation "my_table" does not exist
LINE 1: INSERT INTO "public"."my_table" ("1", "1", "Vitas", "a#i.ua", "..
How to avoid this error?
Thanks in advance!
Rant
You get this "column ... does not exist" error with INSERT INTO "public"."my_table" ("1", ... - because quotes around the "1" mean this is an identifier, not literal.
Even if you fix this, the query still will give error, because of missing VAULES keyword, as Jan noticed in other answer.
The correct form would be:
INSERT INTO "public"."my_table" VALUES ('1', ...
If this SQL was autogenerated by sqlite, bad for sqlite.
This great chapter about SQL syntax is only about 20 pages in print. My advice to whoever generated this INSERT, is: read it :-) it will pay off.
Real solution
Now, to the point... To transfer table from sqlite to postgres, you should use COPY because it's way faster than INSERT.
Use CSV format as it's understood on both sides.
In sqlite3:
create table tbl1(one varchar(20), two smallint);
insert into tbl1 values('hello',10);
insert into tbl1 values('with,comma', 20);
insert into tbl1 values('with "quotes"', 30);
insert into tbl1 values('with
enter', 40);
.mode csv
.header on
.out tbl1.csv
select * from tbl1;
In PostgreSQL (psql client):
create table tbl1(one varchar(20), two smallint);
\copy tbl1 from 'tbl1.csv' with csv header delimiter ','
select * from tbl1;
See http://wiki.postgresql.org/wiki/COPY.
Seems there is missing "VALUES" keyword:
INSERT INTO "public"."my_table" VALUES (...)
But! - You have to insert values with appropriate quotes - single quotes for text and without quotes for numbers.