Cell arrays to numeric type in table

Hi, I am currently parsing a document that contains various numeric and string data. I am parsing it into cell arrays and then trying to put values in either a table or a struct array. I have tried using both a table and a struct array and found slightly more success using a table because I can specify the types of the variable names when initializing them. Where I am running into an issue is when trying to put the numeric types into my table. My table has predefined variables occasionally taking in int64 or double data. I parse the data using this code, where ii is cycling through the filelines:

for ii = 1 : n
    % ii = 1
    % while ~ EOF(1) DO BEGIN
    % line = '';
    line = fgetl(fid);
    % disp(line)
    lineparts = split(line,',');
    a = find(strcmp(extractBetween(lineparts,1,1), '"') == 1);
    for i = 1 : numel(a)
        lineparts(a(i)) = strtrim(extractBetween(lineparts(a(i)), 2, strlength(lineparts(a(i)))-1)); 

which will parses the string data correctly, but once it reaches the first numeric value I get this error "Conversion to <some numeric type> from cell is not possible." My attempted solutions so far have been to use the cell2mat function in order to turn cell array into a number, however, when I try this it tells me that conversion from char to number and I get this error "converstion to cell from char is not possible". My current metod is especially convoluted because I am having to cherrypick each piece of data that I know should be a numeric type using this if statement, where j is cycling through each parsed item:

    for j = 1 : numel(lineparts)
        if j > 7 && j < 25 || j == 29 || j == 30 || j >31 && j < 38 || j > 38 && j < 49 || j == 51
            disp(j)
            disp(lineparts(j))
            lineparts(j) = cell2mat(lineparts(j));
        end
        rec(ii,j) = lineparts(j);

(rec is the table where I am placing the data). Any help would be appreciated, thanks so much!

[dpb]

I think you need to show us the input file -- my first guess is that one could use some of the more exotic options in the import object to solve most, if not all, the issues.

But that would be moving back to the point at which the data are first imported.

In general, the best way to solve a problem is to not create it in the first place -- if we can import the data correctly to begin with, then we don't have to try to clean it up after the fact.