I am executing a very big (3 gigabytes) SQL file via the command line. It is too big to be opened in the SQL Server Management Studio. After several minutes, the tool returns a syntax error.
Msg "102", Level "15", State "1", Server "XYZ\XYZ", Line 20 "Unclosed
quotation mark after the character string "text3
"."
Please note the line break after "text3!
My question is: How can I find the location of the error?
I need to somehow search the big file. Preferarbly with vim. However, I have no idea how to look for that error. The text text3 appears many times in the file. As said, I cannot open the file in the SQL Server Management Studio. The error is also not in Line 20. So I am not sure what that Line 20 in the error message even means? Maybe I can somehow make use of that line break.
if you have big file with small batches you will launch SQL Server Profiler (SSMS Menu Tools) choose Events about Errors and Profiler catch text of batch with error. And you can find bad batch.
My solution to similar issues is divide and conquer.
Split the file into halves on a command border i.e. ';'
Try to execute first half, then the second.
Repeat the halving in the offending file until the haystack is small enough to see the needle.
Sometimes the chopping is enough to make the problem go away.
Related
I have some sensitive information that I need to import into SQL Server that is proving to be a challenge. I'm not sure what the original database that housed this information was, but I do know it is provided to us in a Unix fixed length text file with LF row terminator. I have two files: a small file that covers a month's worth of data, and a much larger file that covers 5 years worth of data. I have created a BCP format file and command that successfully imports and maps the data to my SQL Server table.
The 5 year data is supposedly in the same format, so I've used the same command and format file on the text file. It starts processing some records, but somewhere in the processing (after several thousand records), it throws Unexpected EOF encountered and I can see in the database some of the rows are mapped correctly according to the fixed lengths, but then something goes horribly wrong and screws up by inserting parts of data in columns they most definitely do not belong in. Is there a character that would cause BCP to mess up and terminate early?
BCP Command: BCP DBTemp.dbo.svc_data_temp in C:\Test\data2.txt -f C:\test\txt2.fmt -T -r "0x0A" -S "stageag,90000" -e log.rtf
Again, format file and command work perfectly for the the smaller data set, but something in the 5 year dataset is screwing up BCP.
Thanks in advance for the replies!
So I found the offending characters in my fixed width file. Somehow whoever pulled the data originally (I don't have access to the source), escaped (or did not escape correctly) the double quotes in some of the text, resulting in some injection of extra spaces breaking the fixed width guidelines we were supposed to be following. After correcting the double quotes by hex editing the file, BCP was able to process all records using the format file without issue. I had used the -F and -L flags to examine certain rows of the data and to narrow it down to where I could visually compare the rows that were ok and the rows where the problems started to arise, which led me to discover the double quotes issue. Hope his helps for somebody else if they have an issue similar to this!
I am trying to execute a query, after reading the content from a SQL Script file, assigning it to a variable and then executing the content. Then I get this error saying Could not find stored procedure 'ÿþ'. Please help me understand the issue. Thank you.
Info:
SQL Server 2014
SSMS Version - 12.0.4100.1
ÿþ is one way to interpret the two bytes of the the UTF-16 byte order mark, which is \xFF and \xFE.
You get those two letters when you read a file that has been saved in the UTF-16 encoding with a tool that is unaware of—or, more likely, was not configured to use—Unicode.
For example, when you edit a text file with Windows Notepad and select "Unicode" as file encoding when you save it, Notepad will use UTF-16 to save the file and will mark it with the said two bytes at the start.
If whatever thing you use to read the file is unaware of the fact that the file is Unicode, then it will use the default byte encoding of your computer to decode that text file.
Now, if that default encoding happens to be Windows-1252, like in your case, then ÿþ is what you get, because there \xFF is ÿ and \xFE is þ.
Consequently, when presented with ÿþ, SQL Server thinks it must be the name of a stored procedure, because stored procedures are the only statements that you can run by mentioning just their name. And it dutifully reports that it can't find a procedure of that name.
(Using postgres 9.4beta2)
I have a dump that I want to import. I have done this with the 'psql' command, as elsewhere it is noted that this is required when using COPY FROM stdin:
psql publishing < publishing.dump.20150211160001
I get this syntax error:
ERROR: syntax error at or near "fbc61bc4"
LINE 1: fbc61bc4-2875-4a3a-8dec-91c8d8b60bcc root
The offending line in the dump file is the one after the COPY statement, here are both those lines together:
COPY content_fragment (id, content, name, content_item_id, entity_version) FROM stdin;
fbc61bc4-2875-4a3a-8dec-91c8dcontent Content for root content fbc61bc4-2875-4a3a-8dec-91c8d8b60bcc 0
The items in the data appear to be tab separated. I am wondering given that the error message says at or near "fbc61bc4", but the full string is "fbc61bc4-2875-4a3a-8dec-91c8dcontent", is psql not liking the '-' character?
This kind of error happens when the COPY itself fails because the table doesn't exist, or one of the mentioned columns doesn't, or the user lacks the permission to write into it, etc...
As COPY fails, the SQL interpreter continues to the next line and interpret it as if was an SQL statement, although it's actually data meant to be fed to COPY. Generally this leads to a syntax error, preceded by the error telling why the COPY failed (and often followed by tons of errors if there are many lines of data).
See another question: psql invalid command \N while restore sql, which shares the same root cause and has some useful comments.
I'm working on a project where I have to parse a bunch of .csv files, all of different formats and containing different kinds of data through some C++ functions. After that I extract data from the files and create a .sql file that can be imported in psql to insert the data into a PostgreSQL database at a later stage.
But I am not able to figure out the correct syntax for the .sql file. Here is a sample table and a sample .sql file reproducing the same errors I am getting:
Table Creation Code:
CREATE TABLE "Sample_Table"
(
"Col_ID" integer NOT NULL,
"Col_Message" character varying(50),
CONSTRAINT "Sample_Table_pkey" PRIMARY KEY ("Col_ID" )
)
insertion.sql (after the copy line, fields separated by a single tab character)
copy Sample_Table (Col_ID, Col_Message) from stdin;
1 This is Spaaarta
2 Why So Serious
3 Baazinga
\.
Now if I execute the above sql file, I get the following error:
ERROR: syntax error at or near "1"
LINE 2: 1 This is Spaaarta
^
********** Error **********
If it can help, I'm running a PostgreSQL 9.1 release, and all the above queries were executed through PGAdmin III Software.
PgAdmin doesn't support executing COPY commands in the same way that psql does (or at least, it didn't the last time I tried it with version 1.14). Use psql to execute the script, or use INSERT statements.
Three things to check:
Is there actually exactly one tab characters between the columns? Spaces are a no-go.
Are there more error messages? I'm missing at least one. (See below)
When you force case sensitive table and column names you have to do this consequently. Therefore you must write this:
copy "Sample_Table" ("Col_ID", "Col_Message") from stdin;
Otherwise you will get theese errors:
psql:x.sql:1: ERROR: relation "sample_table" does not exist
psql:x.sql:5: invalid command \.
psql:x.sql:5: ERROR: syntax error at or near "1"
LINE 1: 1 This is Spaaarta
^
With these things in place I can use your example data successfully.
EDIT Bug change: The questioner now has
ERROR: invalid input syntax for integer: "1 'This is Spaaarta'"
So something with the 1 is not OK.
My guess is, that this is an encoding problem. Windows with it's UTF-16 stuff might be the culprit here.
Debugging these kind of problems other the web is not easy, because to many semi-intelligent programs are in the line, most of them like to adjust "a few" things.
But first check a few things in psql:
\encoding
show client_encoding;
show server_encoding;
According to the pastebin data these should be the same and one of "SQL_ASCII", "LATIN1" or "UTF-8".
If they already are or if adjusting them does not help: Unix/Linux/cygwin has a hexdump -C x.sql program, post its output to pastebin. DO NOT USE the hexdump from any Windows editor like ultraedit - they have fooled me several times. When transferring the file to Linux be sure to use binary transfer.
I have a server log file which is constantly updated.
after some script execution, I want to collect the relevant part of my execution from the server log into an execution log.
Basically, I need to capture the last line number of my server log before the test started (which I already know how to do), say X, and after execution, copy the lines from X to the new end of server log, now, X+1000.
How do I copy only lines X to X+1000?
Thanks, Assaf
Try this
open("execution.log", "w").write("\n".join(open("server.log").readlines()[X:X+1000]))