Ok... first of all, I made no real attempt to figure out what the names of the fields are. Somewhere, someone has a RECORD LAYOUT of what the actual fields are and so my example is just that... an example.

Second, someone needs to crown whomever decided that the date of the call should only have month and day. Why did they do that? To save 2 characters? I recommend that someone talk with the person that's providing this data and get that huge mistake repaired right away.

Shifting gears, we don't actually need SSIS for this. Yes, it's one of the tools that you could use for this but I never do. I've always done these types of simple imports and parses using T-SQL and never got out of the habit.

Shifting to yet another gear, there are a dozen different ways to import and parse this data. Since the OP appears (I could certainly be mistaken there) to be just starting out in the world of doing such imports, I'm taking the super simple mode in a fashion similar to what JLS did. Again, I didn't hazard a guess as to what the field names are. There are also some fields that I may have missed parsing on because some of what could be 2 fields looked like just one. You need the RECORD LAYOUT to tell and you'll also need the RECORD LAYOUT to figure out how Col05 should be split.

So, here we go. Step 1 is to import the data. This could be done using a BCP format file but, again, I'm trying to keep it simple until someone actually finds the RECORD LAYOUT so we can be more definitive. My testing was done by saving the file (that the OP provided) in the C:\Temp directory on my desktop box and the BULK INSERT will import from there. Obviously you'll need to change a bit of code for that and you'll need to make the dynamic if you want to make the code handle different files, but all that is comparatively easy to do once you have the hard-coding done and tested.

Here's a simple method to import the data...

CREATE TABLE #MyHead (CDRData VARCHAR(300))

BULK INSERT #MyHead

FROM 'C:\Temp\T20140503.txt'

WITH (

FIELDTERMINATOR ='',

ROWTERMINATOR =''

)

;

Since we're importing whole rows, I forced an empty FIELDTERMINATOR. Yeah, you could have used the BLOB option here. Like a said, there's a dozen differnent ways to do this. Pick one.

Something else to notice is the double "newline" ROWTERMINATOR. That actually happens in the text file and makes it look like there's a blank line between the CDRs. Using the double newline terminator makes it so those blank lines disappear during the import.

Next, is to do the split of the fixed-field-length data like JLS did. To reiterate, some of the fields might need additional splitting but I don't know what they are because I don't have the RECORD LAYOUT. We do know that what I'm calling Col05 is going to need some additional post-process attention as will the call date and duration fields. As soon as the OP coughs up the RECORD LAYOUT, we can do more pretty easily using DelimitedSplit8K on that particular field.

SELECT CallDT = RTRIM(SUBSTRING(CDRData, 2,15))

,CallDuration = RTRIM(SUBSTRING(CDRData, 18,10))

,Col03 = RTRIM(SUBSTRING(CDRData, 29, 8))

,Col04 = RTRIM(SUBSTRING(CDRData, 37, 5))

,Col05 = RTRIM(SUBSTRING(CDRData, 42,26))

,Col06 = RTRIM(SUBSTRING(CDRData, 68, 1))

,Col07 = RTRIM(SUBSTRING(CDRData, 69, 1))

,Col08 = RTRIM(SUBSTRING(CDRData, 70,38))

,Col09 = RTRIM(SUBSTRING(CDRData,108, 6))

,Col10 = RTRIM(SUBSTRING(CDRData,114,21))

,Col11 = RTRIM(SUBSTRING(CDRData,135,19))

,Col12 = RTRIM(SUBSTRING(CDRData,154, 9))

,Col13 = RTRIM(SUBSTRING(CDRData,163, 2))

,Col14 = RTRIM(SUBSTRING(CDRData,165,99))

FROM #MyHead

;

That's pretty much it except maybe for some datatype conversions. This is also the way I'll typically start an import project because it's easy to troubleshoot. Once I have this type of import running, I'll generally convert it to use a BCP format file and a staging table that has the actual columns I need along with the correct datatypes.

JLS may be spot on with his field names... I just didn't want to presume. He also took a shot at Col05 using DelimitedSplit8K but (IMHO) the OP needs to get the RECORD LAYOUT and the "Content Description" of what that field can actually contain before he can be certain of what to get out of that field.

The reason why I keep going on about the RECORD LAYOUT is because what the OP provided and what JLS used doesn't appear to actually line up with the data in the text file the OP provided. He also appears to have missed the fact that the file contains at least one other field that starts at character 165.