![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
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 |
#3
| |||
| |||
|
|
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 |
#4
| |||
| |||
|
|
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 |
#5
| |||
| |||
|
|
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 |
![]() |
| Thread Tools | |
| Display Modes | |
| |