[gdal-dev] how to use the filter option -where within an mysql request?

[Stefan Schantz]

Even,
thank  you for the quick reponse.
My OGR-Version is "GDAL 1.7.2, released 2010/04/23", so it explains the 
errors.

My main issue is, that I want to set up a WMS-Time with UMN 
Mapserver/OGR/MySQL and I couldn't get it work, because I didn't get any 
datas.
For testing reasons I tried it with ogrinfo and got these errors. I 
thought, that the parameter "FILTER" in the mapfile uses perhaps the 
option "where" in ogr.
So I have to try, whether it works , if I recompile the mapserver with a 
newer GDAL version.
Thank you!

Best regards to France,
Stefan


Am 20.12.2011 13:50, schrieb Even Rouault:
> Stefan,
>
> Please always mention the GDAL/OGR version you are using in your reports. It
> will save the readers from figuring out from the error message that you must use
> GDAL 1.7.x or an earlier version.
>
> The -where "end_measure = '2011-12-20'" clause doesn't work in GDAL 1.7.x or
> earlier because the code didn't support comparison on DateTime fields (the error
> message mentions list of binary fields, but DateTime fields too)
>
> I've done a quick test on GDAL 1.9.0beta1 and you can use comparisons on date,
> but they seem to be string based. And you have to respect the format of the
> string serialization used by OGR. In your case, it would be -where "end_measure
> = '2011/12/20  0:00:00'"
>
> However, there's no advantage of using -where when you already use -sql. The
> -sql is directly forwarded to the SQL engine of the RDBMS (when the OGR driver
> is the one of a RDBMS of course), so it will run faster than -where which,
> depending on situations, can be evaluated on OGR side.
> - On a layer which is already the result of -sql, the -where clause is always
> evaluated on OGR side, after the evaluation of -sql
> - If the layer is directly a table name, then the -where clause is generally
> forwarded to the server. (It might depend on the OGR driver however).
>
> So, as a rule of thumb, you can remember that there's no point in using both
> -sql and -where.
>
> Best regards,
>
> Even
>