BULK INSERT skips a row

Hi. Not sure if this is a bug with bulk insert or standard behaviour.
We have a flat file with a header record. A simplified example follows:
HEADER
John,Smith
Fred,Bloggs
But when we set bulk insert to skip the first row it actually skips the
John,Smith row as well. Run the script below after saving the CSV data out
to a file called user.csv...
create table [User]
(
FirstName varchar ( 32 ),
LastName varchar ( 32 )
)
bulk insert [User] from 'user.csv'
with
(
FIRSTROW = 2,
DATAFILETYPE = 'char',
FIELDTERMINATOR = ',',
ROWTERMINATOR = '\n'
)
select * from [user] -- only one record
Please help!!
McGy
[url]http://mcgy.blogspot.com[/url]Anyone with ideas on how to get around this limitation?
McGy
[url]http://mcgy.blogspot.com[/url]
"McGy" <anon@.anon.com> wrote in message
news:#1#7JPAVGHA.5332@.tk2msftngp13.phx.gbl...
> Hi. Not sure if this is a bug with bulk insert or standard behaviour.
> We have a flat file with a header record. A simplified example follows:
> HEADER
> John,Smith
> Fred,Bloggs
> But when we set bulk insert to skip the first row it actually skips the
> John,Smith row as well. Run the script below after saving the CSV data out
> to a file called user.csv...
> create table [User]
> (
> FirstName varchar ( 32 ),
> LastName varchar ( 32 )
> )
> bulk insert [User] from 'user.csv'
> with
> (
> FIRSTROW = 2,
> DATAFILETYPE = 'char',
> FIELDTERMINATOR = ',',
> ROWTERMINATOR = '\n'
> )
> select * from [user] -- only one record
> Please help!!
> --
> McGy
> [url]http://mcgy.blogspot.com[/url]
>
>|||Some solutions are
1. Pre-process the file to remove the header line (use a DOS
or Unix-like utility, for example).
2. Bulk insert the data into a staging table with one column,
then parse the data into columns using SQL instead of the
bulk insert process.
3. Use SQL Server Integration Services. I'm no expert, but I believe
it can skip (or import into a different table) rows based on the
contents of the row, which bulk insert cannot do.
The FIRSTROW parameter for bulk insert, as you have discovered,
is not a FIRST_LINE_OF_THE_TEXT_FILE parameter.
Steve Kass
Drew University
McGy wrote:

>Anyone with ideas on how to get around this limitation?
>--
>McGy
>[url]http://mcgy.blogspot.com[/url]
>
>"McGy" <anon@.anon.com> wrote in message
>news:#1#7JPAVGHA.5332@.tk2msftngp13.phx.gbl...
>
>
>|||McGy (anon@.anon.com) writes:
Alas, this is standard behaviour.
BULK INSERT and BCP live in a very squared world. They don't think in
terms of lines, they think in terms of records and fields. (But calls them
rows and columns to matters.)
The first field is from the beginning of file until the terminator for
the first field. (For terminated fields. Fields can also be fix-length,
or include a length-prefix.) The second field lasts until the terminator
for that field. And so on, up to the last field which lasts until the
terminator for that field. That terminator is called a "row terminator",
but as long as BCP is not reading the last field, the terminator carries
no meaning. Once the last field has been read, bulk copy starts with
the first field again.
This has some advantages and divantages. On the flip side, is that
you can handle embedded row terminators, for instance embedded newlines
(except in the last field). The bad part is that you can't skip a header
which does not conform with the file. Because as far as BCP is concerned,
that header is part of the first field.
The workaround is to run a program first that strips the header, which
for a large file is not very appealing.
I know I have subumitted a suggestion for an improvement to bulk copy
for a future release of SQL Server, so that you should be able to describe
a header to be skipped. The suggestion is on
http://lab.msdn.microsoft.com/productfeedback/ but alas, the site
appears to experience some problems right now, so I cannot give the
exact link. But when it's back, search for by name, "bulk" and SQL 2005
to find it and vote for it.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

BUILTIN\ADMINISTRATORS EVENT 6013

I have been getting a weird SQL event message the applications event log. I
am running
sql 2000 sp 3a
windows 2003 standard server sp1
I removed the BUILTIN\ADMINISTRATORS account. Is there somthing I missed
when removing this account. I was told the NT AUTHORITY\SYSTEM account can
lead to sql injection attacks. Some say just add the builtin administrators
account back but it goes against best practices and I would like to work
around it. iS this possible... Seems like I have been running into more
problems by removing this account. Any help is appreciated.
Sqllib error: OLEDB Error encountered calling IDBInitialize::Initialize. hr
= 0x80040e4d. SQLSTATE: 42000, Native Error: 18456
Error state: 1, Severity: 14
Source: Microsoft OLE DB Provider for SQL Server
Error message: Login failed for user 'NT AUTHORITY\SYSTEM'.
0000: 2d 20 43 6f 64 65 3a 20 - Code:
0008: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
0010: 30 30 30 30 30 34 39 31 00000491
0018: 2d 20 43 61 6c 6c 3a 20 - Call:
0020: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
0028: 30 30 30 30 30 33 39 37 00000397
0030: 2d 20 50 49 44 3a 20 20 - PID:
0038: 30 30 30 30 32 38 38 30 00002880
0040: 2d 20 54 49 44 3a 20 20 - TID:
0048: 30 30 30 30 34 38 30 34 00004804
0050: 2d 20 43 4d 44 3a 20 20 - CMD:
0058: 43 3a 5c 57 49 4e 44 4f C:\WINDO
0060: 57 53 5c 53 79 73 74 65 WS\Syste
0068: 6d 33 32 5c 76 73 73 76 m32\vssv
0070: 63 2e 65 78 65 20 20 20 c.exe
0078: 2d 20 55 73 65 72 3a 20 - User:
0080: 4e 54 20 41 55 54 48 4f NT AUTHO
0088: 52 49 54 59 5c 53 59 53 RITY\SYS
0090: 54 45 4d 20 20 20 20 20 TEMvssvc.exe is the Volume Shadow Copy service I believe. I don't know why
it would be trying to connect to the SQL instance but I haven't really
played with it much so it may need to for some reason (it's a legit
Microsoft service). Anyway, it would appear it's running under the
local system account, which is fine, and if you want that functionality
to work you can just sp_grantlogin to 'NT AUTHORITY\SYSTEM'. This is
different to granting all local admins (ie. 'BUILTIN\Administrators')
sysadmin privileges (which I wouldn't recommend), but some apps (mostly
services like Microsoft Search (full-text) on SQL 2000 boxes for
instance) need to talk to SQL Server and typically use the local system
account. I wouldn't see that as a big security hole.
SQL Injection has nothing to do with granting 'NT AUTHORITY\SYSTEM' a
login to the SQL instance. If the SQL Server service is running under
an admin account (like the local system account for instance, which is
pretty common) then if an attacker exploits some weakness in a user
application (that doesn't validate the T-SQL code it's sending to the
SQL server) then they can use a SQL injection attack to take control of
the box (because SQL Server would do what they asked it to, within the
permissions granted to their SQL login, and that might mean some Windows
admin function, which the SQL instance could do if it was a local admin,
like local system).
SQL injection is a possible factor in poorly written applications that
use SQL Server on the back-end. It is not related to which logins can
connect to your SQL instance, but is more relevant to the account under
which your SQL instance runs on the OS (and which login to the SQL box
the poorly written SQL app uses - hopefully not a sysadmin login).
*mike hodgson*
http://sqlnerd.blogspot.com
JD wrote:

>I have been getting a weird SQL event message the applications event log. I
>am running
>sql 2000 sp 3a
>windows 2003 standard server sp1
>I removed the BUILTIN\ADMINISTRATORS account. Is there somthing I missed
>when removing this account. I was told the NT AUTHORITY\SYSTEM account can
>lead to sql injection attacks. Some say just add the builtin administrators
>account back but it goes against best practices and I would like to work
>around it. iS this possible... Seems like I have been running into more
>problems by removing this account. Any help is appreciated.
>Sqllib error: OLEDB Error encountered calling IDBInitialize::Initialize. hr
>= 0x80040e4d. SQLSTATE: 42000, Native Error: 18456
>Error state: 1, Severity: 14
>Source: Microsoft OLE DB Provider for SQL Server
>Error message: Login failed for user 'NT AUTHORITY\SYSTEM'.
>
>0000: 2d 20 43 6f 64 65 3a 20 - Code:
>0008: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
>0010: 30 30 30 30 30 34 39 31 00000491
>0018: 2d 20 43 61 6c 6c 3a 20 - Call:
>0020: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
>0028: 30 30 30 30 30 33 39 37 00000397
>0030: 2d 20 50 49 44 3a 20 20 - PID:
>0038: 30 30 30 30 32 38 38 30 00002880
>0040: 2d 20 54 49 44 3a 20 20 - TID:
>0048: 30 30 30 30 34 38 30 34 00004804
>0050: 2d 20 43 4d 44 3a 20 20 - CMD:
>0058: 43 3a 5c 57 49 4e 44 4f C:\WINDO
>0060: 57 53 5c 53 79 73 74 65 WS\Syste
>0068: 6d 33 32 5c 76 73 73 76 m32\vssv
>0070: 63 2e 65 78 65 20 20 20 c.exe
>0078: 2d 20 55 73 65 72 3a 20 - User:
>0080: 4e 54 20 41 55 54 48 4f NT AUTHO
>0088: 52 49 54 59 5c 53 59 53 RITY\SYS
>0090: 54 45 4d 20 20 20 20 20 TEM
>
>|||Thank you for your response. That did shed some light on the problem. Seems
like are backup admin selected to backup with veritas sql client and had it
misconfigured.
JD
"Mike Hodgson" <e1minst3r@.gmail.com> wrote in message news:%23Vlz6S0OGHA.183
2@.TK2MSFTNGP11.phx.gbl...
vssvc.exe is the Volume Shadow Copy service I believe. I don't know why it
would be trying to connect to the SQL instance but I haven't really played w
ith it much so it may need to for some reason (it's a legit Microsoft servic
e). Anyway, it would appear it's running under the local system account, wh
ich is fine, and if you want that functionality to work you can just sp_gran
tlogin to 'NT AUTHORITY\SYSTEM'. This is different to granting all local ad
mins (ie. 'BUILTIN\Administrators') sysadmin privileges (which I wouldn't re
commend), but some apps (mostly services like Microsoft Search (full-text) o
n SQL 2000 boxes for instance) need to talk to SQL Server and typically use
the local system account. I wouldn't see that as a big security hole.
SQL Injection has nothing to do with granting 'NT AUTHORITY\SYSTEM' a login
to the SQL instance. If the SQL Server service is running under an admin ac
count (like the local system account for instance, which is pretty common) t
hen if an attacker exploits some weakness in a user application (that doesn'
t validate the T-SQL code it's sending to the SQL server) then they can use
a SQL injection attack to take control of the box (because SQL Server would
do what they asked it to, within the permissions granted to their SQL login,
and that might mean some Windows admin function, which the SQL instance cou
ld do if it was a local admin, like local system).
SQL injection is a possible factor in poorly written applications that use S
QL Server on the back-end. It is not related to which logins can connect to
your SQL instance, but is more relevant to the account under which your SQL
instance runs on the OS (and which login to the SQL box the poorly written
SQL app uses - hopefully not a sysadmin login).
mike hodgson
http://sqlnerd.blogspot.com
JD wrote:
I have been getting a weird SQL event message the applications event log. I
am running
sql 2000 sp 3a
windows 2003 standard server sp1
I removed the BUILTIN\ADMINISTRATORS account. Is there somthing I missed
when removing this account. I was told the NT AUTHORITY\SYSTEM account can
lead to sql injection attacks. Some say just add the builtin administrators
account back but it goes against best practices and I would like to work
around it. iS this possible... Seems like I have been running into more
problems by removing this account. Any help is appreciated.
Sqllib error: OLEDB Error encountered calling IDBInitialize::Initialize. hr
= 0x80040e4d. SQLSTATE: 42000, Native Error: 18456
Error state: 1, Severity: 14
Source: Microsoft OLE DB Provider for SQL Server
Error message: Login failed for user 'NT AUTHORITY\SYSTEM'.
0000: 2d 20 43 6f 64 65 3a 20 - Code:
0008: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
0010: 30 30 30 30 30 34 39 31 00000491
0018: 2d 20 43 61 6c 6c 3a 20 - Call:
0020: 53 51 4c 43 4f 4e 4e 43 SQLCONNC
0028: 30 30 30 30 30 33 39 37 00000397
0030: 2d 20 50 49 44 3a 20 20 - PID:
0038: 30 30 30 30 32 38 38 30 00002880
0040: 2d 20 54 49 44 3a 20 20 - TID:
0048: 30 30 30 30 34 38 30 34 00004804
0050: 2d 20 43 4d 44 3a 20 20 - CMD:
0058: 43 3a 5c 57 49 4e 44 4f C:\WINDO
0060: 57 53 5c 53 79 73 74 65 WS\Syste
0068: 6d 33 32 5c 76 73 73 76 m32\vssv
0070: 63 2e 65 78 65 20 20 20 c.exe
0078: 2d 20 55 73 65 72 3a 20 - User:
0080: 4e 54 20 41 55 54 48 4f NT AUTHO
0088: 52 49 54 59 5c 53 59 53 RITY\SYS
0090: 54 45 4d 20 20 20 20 20 TEM