Trying this workspace,
I get an error saying 'owner' feature type does not exist. The FeatureWriter output format is SpatiaLite and a template.sqlite database is used. For both feature types "Use existing" table handling is selected. Parcel geometry type is wkb_polygon and owner is wkb_none. The 'owner' table exists in the template. Could it be a FeatureWriter error managing SpatiaLite?
The good news is that this will work in FME 2022. The SpatiaLite reader/writer got a complete overhaul to include reading non-spatial tables. You just need to use 2022 (should be released in under 1 month now and the beta is fairly stable too) and use the format "SpatiaLite". The older format is renamed to "SQLite Spatial (GDAL) (deprecated)" and that's the one to avoid.
The good news is that this will work in FME 2022. The SpatiaLite reader/writer got a complete overhaul to include reading non-spatial tables. You just need to use 2022 (should be released in under 1 month now and the beta is fairly stable too) and use the format "SpatiaLite". The older format is renamed to "SQLite Spatial (GDAL) (deprecated)" and that's the one to avoid.
Oh, I should mention that if you want to do this in 2021 or earlier, use the SpatiaLite format to read the Parcels table and a separate reader in SQLite format to read the Owner table. Annoying, but like I said, resolved in 2022.
That is great! I hope to try the new version soon. Do you know if my "wish list" ("Improve SpatiaLite support
" in Ideas section) is included in FME 2022?
That is great! I hope to try the new version soon. Do you know if my "wish list" ("Improve SpatiaLite support
" in Ideas section) is included in FME 2022?
I don't think so. I can still create a datatype of varchar in 2022. But although that's odd, I don't think it's necessarily a problem. As I understand it, SQLite is very flexible in its data types and will accept any data type name and any type of data into it. So it's probably not a priority to change anything, but I'll check with our developers anyway why it is still available.
I don't think so. I can still create a datatype of varchar in 2022. But although that's odd, I don't think it's necessarily a problem. As I understand it, SQLite is very flexible in its data types and will accept any data type name and any type of data into it. So it's probably not a priority to change anything, but I'll check with our developers anyway why it is still available.
But the Readers ignore VARCHAR(0) and make it TEXT <infinite> which is a problem for converting to other databases. The DDL schema stored in Spatialite should be honoured, even if internally it is translated to limited data types.
I don't think so. I can still create a datatype of varchar in 2022. But although that's odd, I don't think it's necessarily a problem. As I understand it, SQLite is very flexible in its data types and will accept any data type name and any type of data into it. So it's probably not a priority to change anything, but I'll check with our developers anyway why it is still available.
Hi @kimo ,
Following up here as well from your other post - there is a bug with the SpatiaLite format in FME 2022 beta currently if the original table column was created with "VARCHAR" instead of "varchar" (internal ref: FMEENGINE-72938).
We'll update here when it's been resolved.
-Andrea