What I do in SQL Server is create a table with the parsing information and Cartesian join it to the string data.
Select the data table key, the field name from the parsing information and the substring using the Mid function with the parameters drawn from the parsing information table. This results in very tall narrow output with fields for the data key, the field name and the value, essentially an Entity, Attribute, Value construct.
Then simply Pivot (Cross Tab) to bring the values out into multiple fields.
Access could do the same.
This technique uses the strengths of the engine to process data as sets and is orders of magnitude faster than any RBAR approach parsing the data line by line. I expect the fixed width import in Access uses a similar technique. Similarly with SQL Server's fixed width SSIS imports.
The parsing data I use for this system includes the output datatype and any conversion formulae in the table to arrive at the stored value. This supports a completely generalised system where parsing information is used to generate dynamic sql, ultimately writing the data to a table or recordset. It is essentially an easy to configure enhanced SSIS substitute.
When I first created it, the server was returning 15,000 records with 16 fields from 128 character wide strings in less than six seconds. I have not timed it since we upgraded the server last year but the performance of everything else on the new server is far and way faster than on the old server.
Select the data table key, the field name from the parsing information and the substring using the Mid function with the parameters drawn from the parsing information table. This results in very tall narrow output with fields for the data key, the field name and the value, essentially an Entity, Attribute, Value construct.
Then simply Pivot (Cross Tab) to bring the values out into multiple fields.
Access could do the same.
This technique uses the strengths of the engine to process data as sets and is orders of magnitude faster than any RBAR approach parsing the data line by line. I expect the fixed width import in Access uses a similar technique. Similarly with SQL Server's fixed width SSIS imports.
The parsing data I use for this system includes the output datatype and any conversion formulae in the table to arrive at the stored value. This supports a completely generalised system where parsing information is used to generate dynamic sql, ultimately writing the data to a table or recordset. It is essentially an easy to configure enhanced SSIS substitute.
When I first created it, the server was returning 15,000 records with 16 fields from 128 character wide strings in less than six seconds. I have not timed it since we upgraded the server last year but the performance of everything else on the new server is far and way faster than on the old server.