How can it be an inherent limitation of sqlite if it works in CP2.2?
Because the issue isn’t really that 3.0 can’t handle as many columns as 2.2, it’s that the 3.0 version of the pipeline makes so many more measurements that you run up against the inherent SQLite column limit.
Your original 2.2 pipeline creates as table that’s ~920 columns wide (and I didn’t have the metadata CSV loaded, so probably 950 when all is said and done). There are 420 texture columns in total, so about 210 from each scale.
In 2.2 you were only measuring texture at one set of angles, an option that you don’t have in 3.0- 3.0 measures all of them. The 3.0 version of your pipeline with only one texture scale would be ~1350 columns wide with the metadata included, 780 of which are texture. So a 3.0 pipeline with 2 texture scales puts us at ~2130 columns, which is above the magic limit of 2000.
The good news is that since these 2130 columns are coming from 3 separate objects, you can use the “Single object view” rather than the “Single object table” mode in ExportToDatabase- from the help:
Single object view creates a single database view to contain the object measurements. A view is a virtual database table which can be used to package together multiple per-object tables into a single structure that is accessed just like a regular table. Choose Single object view if you want to combine multiple objects but using Single object table would produce a table that hits the database size limitations.
I do agree though that it’s likely other people will run into this (or might start running into issues if Texture gives them more than 2000 measurements for any individual object) so I’ll bring up with the team at the software meeting today based on those numbers whether or not we want to revisit the idea of going back to allowing you to choose angles and/or if we want to make major changes to how the Export modules work (which we do have planned for the long run, just not the short run).