We use inline loads with only a few rows when giving examples because that's a very clear way to show example data, and not have to know whether you're loading using SQL, from a QVD, from an Excel file, or whatever. Replace what we load inline with whatever your actual data source is. Those details are usually beside the point, not really relevant to solving the specific question.
In this case, it doesn't matter how many rows you have in the tables. The crosstable is sensitive to the column names and positions, so you'd have to be careful when loading your real table to have things in the right order. You might even want to split the first table into two tables linked by an ID. But it's hard for me to know without knowing your actual data. And it's hard for me to give you exact script without knowing your data sources as well. But assuming you have a lot more fields in both tables, and you're loading from QVDs, it might look something like this, including my split of your first table into two, only "necessary" if you have additional fields in that first table:
StoreData:
LOAD
StoreID
,StoreName
,some
,other
,fields
FROM Store.qvd (QVD)
;
StoreCodes:
CROSSTABLE (Codenum,Code)
LOAD
StoreID
,Code1
,Code2
,Code3
,Code4
,etc. for all codes
FROM Store.qvd (QVD)
;
CodeData:
LOAD
Code
,Type
,Square
,Name
,Something
,SomethingElse
,AndSoOn
FROM Codes.qvd (QVD)
;
But even that's not what I'd really do, because in the real world I'd be breaking apart the data before even storing in QVDs, not breaking it apart loading from QVDs. But I hope I don't have to expand this example even further to get the idea across. In any case, the important insight is to use crosstable to restructure the code portion of the data from the first table, converting columns into rows. This load is not sensitive to how many rows and columns you have, any more than any other load is sensitive to how many rows and columns you have.
