Thanks,
Aaron
Albuquerque, NM
Thanks,
Aaron
Albuquerque, NM
You are on the right track, I would use a SQL statement in a SQLCreator to let the db take the load.
Itay
Aaron
if you need the geometries I'm not convinced that the SQLCreator will make life any easier for you, as they're not supported "out of the box" unless you cast the to something like WKB (which has a performance penalty in itself).
The best long term solution would be to have your dba create spatial views in Oracle with only the necessary parameters, the use the regular GeoDb reader to access them.
That being said, 45 minutes to read 440k features sounds awfully slow. Unless you have a crazy amount of attributes I'm not so sure losing some of them is going to make a big difference. You might want to look into your db and network performance first of all.
David
Thanks for your response. I don't need geometries in this case. In addition, we do have a crazy amount of attributes - 248 total attributes across the three feature classes (69, 103, and 76) - so you can see why I'd prefer to only read in the 6 that I need.
Aaron
in that case the SQLCreator should be perfect. Just use the Oracle Non-Spatial data type and connect as usual.
Remember to fill in "Attributes to expose" in the SQLCreator with the attributes specified in your SELECT-statement.
See also the documentation (http://docs.safe.com/fme/html/FME_Transformers/Default.htm#Transformers/sqlcreator.htm).
David
Aaron