<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br>
Several workarounds come to mind:<br>
- make sure that your features are always retrieved in the same order by <br>
adding an ORDER BY clause to your DATA clause<br></blockquote><div><br></div><div>Hi Even,</div><div><br></div><div>I've already used orderby in the wfs query, however I'm not sure it helps in this case, since the rowindex is assingned to resultindex which starts from 0 as far as I see.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- set the wfs_features_cache_size metadata item<br>
(see <a href="https://mapserver.org/ogc/wfs_server.html?highlight=features_cache_count" rel="noreferrer" target="_blank">https://mapserver.org/ogc/wfs_server.html?highlight=features_cache_count</a>) <br>
so that the result of the first query is entirely cached in RAM<br>
<br></blockquote><div><br></div><div>I just wanted to understand the intended behavior at the moment, so as to imagine what optimizations can be implemented in the MSSQL driver for the query and the pagination support. </div><div>This workaround could probably help for the user, however.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Would that be an option to implement msWFSComputeMatchingFeatures in that<br>
> way so that the original layer is not getting closed and reopened?<br>
<br>
This is likely to be involved as I guess those open/closings are the ones done <br>
in mapquery.c<br>
<br></blockquote><div><br></div><div>We could probably call msLayerGetShapeCount directly and the drivers can make sure not to change the resultset within the implementation.</div><div><br></div><div>Best regards,</div><div><br></div><div>Tamas</div></div></div>