dbTalk Databases Forums  

DTS Package Ignoring CR LF At End of Each Row in Text File

microsoft.public.sqlserver.dts microsoft.public.sqlserver.dts


Discuss DTS Package Ignoring CR LF At End of Each Row in Text File in the microsoft.public.sqlserver.dts forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
RitaG
 
Posts: n/a

Default DTS Package Ignoring CR LF At End of Each Row in Text File - 05-24-2005 , 03:31 PM






Hi.

I'm using SQL Enterprise Manager 8.0 and importing a text file into a SQL
table using a DTS package.
The text file has rows with 542 characters in each row and a CR LF (0D 0A)
at the end of each row in position 543. Using a Hex editor (Ultra-Edit) I was
able to confirm the CR LF at the end of the rows.

However, in the DTS package when I check the properties of the text file, I
notice that the rows are not aligned up starting at position 1 but are all
over the place. The file type is set to ANSI and the Row Delimiter is set to
{CR}{LF}. When I click the Next button I get an error message saying "Could
not find selected row delimiter within the first 8K of data. Is the selected
row delimiter valid?". I click on YES and get the "Fixed Field Column
Positions" form. When I move the position to 542, I see a solid vertical bar
in position 543 which is where the CR LF (0D 0A) is but the DTS is not
recognizing as such and all the data is in 1 very long row.

What's interesting is when I change the Row Delimiter on the previous screen
to LF and then click NEXT to get the "Fixed Field Column Positions" form, the
rows are now separated correctly! I don't understand how that can be when I
can see the 0D 0A in position 543 of the text file when viewed in Ultra-Edit
in Hex mode.

I checked every character (in Hex mode) in the first row to see if there was
something that was throwing it out but they're all legitimate.

Any suggestions will be greatly appreciated!

Rita



Reply With Quote
  #2  
Old   
Allan Mitchell
 
Posts: n/a

Default Re: DTS Package Ignoring CR LF At End of Each Row in Text File - 05-24-2005 , 04:16 PM






Whilst this will not help you it may give you comfort in knowing that I
have also had this. I spent half an hour scratching my head with
UltraEdit

"RitaG" <RitaG (AT) discussions (DOT) microsoft.com> wrote


Quote:
Hi.

I'm using SQL Enterprise Manager 8.0 and importing a text file into a SQL
table using a DTS package.
The text file has rows with 542 characters in each row and a CR LF (0D 0A)
at the end of each row in position 543. Using a Hex editor (Ultra-Edit) I was
able to confirm the CR LF at the end of the rows.

However, in the DTS package when I check the properties of the text file, I
notice that the rows are not aligned up starting at position 1 but are all
over the place. The file type is set to ANSI and the Row Delimiter is set to
{CR}{LF}. When I click the Next button I get an error message saying "Could
not find selected row delimiter within the first 8K of data. Is the selected
row delimiter valid?". I click on YES and get the "Fixed Field Column
Positions" form. When I move the position to 542, I see a solid vertical bar
in position 543 which is where the CR LF (0D 0A) is but the DTS is not
recognizing as such and all the data is in 1 very long row.

What's interesting is when I change the Row Delimiter on the previous screen
to LF and then click NEXT to get the "Fixed Field Column Positions" form, the
rows are now separated correctly! I don't understand how that can be when I
can see the 0D 0A in position 543 of the text file when viewed in Ultra-Edit
in Hex mode.

I checked every character (in Hex mode) in the first row to see if there was
something that was throwing it out but they're all legitimate.

Any suggestions will be greatly appreciated!

Rita


Reply With Quote
  #3  
Old   
RitaG
 
Posts: n/a

Default Re: DTS Package Ignoring CR LF At End of Each Row in Text File - 05-24-2005 , 04:36 PM



Hi Allen,

I opened up the same file in MultiEdit and it does not show the CR LF in the
last position. I'm wondering if UltraEdit places a CR LF automatically if
there is none there but then how does MultiEdit know that the line ends at
position 542?

Hmmmm.

"Allan Mitchell" wrote:

Quote:
Whilst this will not help you it may give you comfort in knowing that I
have also had this. I spent half an hour scratching my head with
UltraEdit

"RitaG" <RitaG (AT) discussions (DOT) microsoft.com> wrote in message
news:RitaG (AT) discussions (DOT) microsoft.com:

Hi.

I'm using SQL Enterprise Manager 8.0 and importing a text file into a SQL
table using a DTS package.
The text file has rows with 542 characters in each row and a CR LF (0D 0A)
at the end of each row in position 543. Using a Hex editor (Ultra-Edit) I was
able to confirm the CR LF at the end of the rows.

However, in the DTS package when I check the properties of the text file, I
notice that the rows are not aligned up starting at position 1 but are all
over the place. The file type is set to ANSI and the Row Delimiter is set to
{CR}{LF}. When I click the Next button I get an error message saying "Could
not find selected row delimiter within the first 8K of data. Is the selected
row delimiter valid?". I click on YES and get the "Fixed Field Column
Positions" form. When I move the position to 542, I see a solid vertical bar
in position 543 which is where the CR LF (0D 0A) is but the DTS is not
recognizing as such and all the data is in 1 very long row.

What's interesting is when I change the Row Delimiter on the previous screen
to LF and then click NEXT to get the "Fixed Field Column Positions" form, the
rows are now separated correctly! I don't understand how that can be when I
can see the 0D 0A in position 543 of the text file when viewed in Ultra-Edit
in Hex mode.

I checked every character (in Hex mode) in the first row to see if there was
something that was throwing it out but they're all legitimate.

Any suggestions will be greatly appreciated!

Rita



Reply With Quote
  #4  
Old   
Allan Mitchell
 
Posts: n/a

Default Re: DTS Package Ignoring CR LF At End of Each Row in Text File - 05-24-2005 , 04:41 PM



Good point.

Maybe what we see is not what we get in UltraEdit then.

Will have to check.

"RitaG" <RitaG (AT) discussions (DOT) microsoft.com> wrote


Quote:
Hi Allen,

I opened up the same file in MultiEdit and it does not show the CR LF in the
last position. I'm wondering if UltraEdit places a CR LF automatically if
there is none there but then how does MultiEdit know that the line ends at
position 542?

Hmmmm.

"Allan Mitchell" wrote:

Whilst this will not help you it may give you comfort in knowing that I
have also had this. I spent half an hour scratching my head with
UltraEdit

"RitaG" <RitaG (AT) discussions (DOT) microsoft.com> wrote in message
news:RitaG (AT) discussions (DOT) microsoft.com:

Hi.

I'm using SQL Enterprise Manager 8.0 and importing a text file into a SQL
table using a DTS package.
The text file has rows with 542 characters in each row and a CR LF (0D 0A)
at the end of each row in position 543. Using a Hex editor (Ultra-Edit) I was
able to confirm the CR LF at the end of the rows.

However, in the DTS package when I check the properties of the text file, I
notice that the rows are not aligned up starting at position 1 but are all
over the place. The file type is set to ANSI and the Row Delimiter is set to
{CR}{LF}. When I click the Next button I get an error message saying "Could
not find selected row delimiter within the first 8K of data. Is the selected
row delimiter valid?". I click on YES and get the "Fixed Field Column
Positions" form. When I move the position to 542, I see a solid vertical bar
in position 543 which is where the CR LF (0D 0A) is but the DTS is not
recognizing as such and all the data is in 1 very long row.

What's interesting is when I change the Row Delimiter on the previous screen
to LF and then click NEXT to get the "Fixed Field Column Positions" form, the
rows are now separated correctly! I don't understand how that can be when I
can see the 0D 0A in position 543 of the text file when viewed in Ultra-Edit
in Hex mode.

I checked every character (in Hex mode) in the first row to see if there was
something that was throwing it out but they're all legitimate.

Any suggestions will be greatly appreciated!

Rita




Reply With Quote
  #5  
Old   
RitaG
 
Posts: n/a

Default Re: DTS Package Ignoring CR LF At End of Each Row in Text File - 05-25-2005 , 10:01 AM



In UltraEdit I copied all the lines of the text file, pasted them in a new
file and then saved the file. Using that file the DTS package was able to
work correctly.

I'm confused..!

"Allan Mitchell" wrote:

Quote:
Good point.

Maybe what we see is not what we get in UltraEdit then.

Will have to check.

"RitaG" <RitaG (AT) discussions (DOT) microsoft.com> wrote in message
news:RitaG (AT) discussions (DOT) microsoft.com:

Hi Allen,

I opened up the same file in MultiEdit and it does not show the CR LF in the
last position. I'm wondering if UltraEdit places a CR LF automatically if
there is none there but then how does MultiEdit know that the line ends at
position 542?

Hmmmm.

"Allan Mitchell" wrote:

Whilst this will not help you it may give you comfort in knowing that I
have also had this. I spent half an hour scratching my head with
UltraEdit

"RitaG" <RitaG (AT) discussions (DOT) microsoft.com> wrote in message
news:RitaG (AT) discussions (DOT) microsoft.com:

Hi.

I'm using SQL Enterprise Manager 8.0 and importing a text file into a SQL
table using a DTS package.
The text file has rows with 542 characters in each row and a CR LF (0D 0A)
at the end of each row in position 543. Using a Hex editor (Ultra-Edit) I was
able to confirm the CR LF at the end of the rows.

However, in the DTS package when I check the properties of the text file, I
notice that the rows are not aligned up starting at position 1 but are all
over the place. The file type is set to ANSI and the Row Delimiter is set to
{CR}{LF}. When I click the Next button I get an error message saying "Could
not find selected row delimiter within the first 8K of data. Is the selected
row delimiter valid?". I click on YES and get the "Fixed Field Column
Positions" form. When I move the position to 542, I see a solid vertical bar
in position 543 which is where the CR LF (0D 0A) is but the DTS is not
recognizing as such and all the data is in 1 very long row.

What's interesting is when I change the Row Delimiter on the previous screen
to LF and then click NEXT to get the "Fixed Field Column Positions" form, the
rows are now separated correctly! I don't understand how that can be when I
can see the 0D 0A in position 543 of the text file when viewed in Ultra-Edit
in Hex mode.

I checked every character (in Hex mode) in the first row to see if there was
something that was throwing it out but they're all legitimate.

Any suggestions will be greatly appreciated!

Rita





Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.