Hi
The WHERE-clause is only available for formats that supports conditional selects, e.g. SQL-based databases. Unfortunately, Shape-files do not support a WHERE-clause in FME and you will have to use e.g. a Tester to only process parts of the data.
If you do many selections on the same big dataset, consider first loading the Shape file(s) into a proper database, e.g. Postgis, which supports WHERE-clauses.
David
Perfect @david_r
Thanks your reply and help. I will make this.
Thanks in Advance,
Danilo de Lima
Yes,
Fme should be made able to query the dbf file and then load only the relevant shapes.
Dbf commander can use sql on dbf, so should fme (without using inlinequerier on the dbf and then merging, because u would still be reading the entire shapefile).
Sounds like a good idea to me..
Yes,
Fme should be made able to query the dbf file and then load only the relevant shapes.
Dbf commander can use sql on dbf, so should fme (without using inlinequerier on the dbf and then merging, because u would still be reading the entire shapefile).
Sounds like a good idea to me..
I agree. It's a pity that not even the DBF reader has a where-clause. You'd think it would be a minor thing to implement. If I wasn't hoping for Shape to die out ASAP, I'd post this as a suggestion for Safe...
Yes,
Fme should be made able to query the dbf file and then load only the relevant shapes.
Dbf commander can use sql on dbf, so should fme (without using inlinequerier on the dbf and then merging, because u would still be reading the entire shapefile).
Sounds like a good idea to me..
@gio i agree too. Its a good idea for SAFE implementing it.
Yes,
Fme should be made able to query the dbf file and then load only the relevant shapes.
Dbf commander can use sql on dbf, so should fme (without using inlinequerier on the dbf and then merging, because u would still be reading the entire shapefile).
Sounds like a good idea to me..
Good feedback. We've added some filtering to CSV reading in FME for example. Note that we still have to read the entire DBF to do any kind of filtering because there is no index or magic available to us. We could make a trivial WHERE clause but to step up to full SQL WHERE power might be more effort than we'd want to roll our own to do.
Would WHERE <filename> <operator> <value> be sufficient?