ThinkGeo.com    |     Documentation    |     Premium Support

SQL Server Stored Procedures with MapSuite

Just wondering whether anyone has SQL Server 2008 and MapSuite Desktop Edition working so that Stored Procedures can be used (instead of the .WhereClause ?) to filter the records shown on a map.... I am looking for ways to increase performance but can't decide whether it will be possible or not.


Thanks,


Dave



Hi David,


Thanks for your question!


We do support Stored Procedures through the use of the MsSql2008FeatureLayer.ExecuteQuery() which allows you to execute a SQL statement directly.



If the filtering is static, you might want to try views.  We use approx 15 views in our app.  Performance is probably better because execution plan is already generated.  Of course you might be doing some sort of dynamic filtering… 
  
 Allen

Ryan - I am guessing it should be MsSql2008FeatureLayer.QueryTools.ExecuteQuery() ? 

I also see MsSql2008FeatureLayer.ExecuteNonQuery - I better look into that as well. 



Allen - mainly I am doing dynamic filtering as it is a ship tracking application. But for the background layers that might come in handy so I will research it.



Hi David,  
  
 The ExecuteQuery() is designed for statements that return results. The ExecuteNonQuery() is for statements that don’t return data to the control, such as Update.

Ryan is correct about ExecuteNonQuery, but it does return a count of records affected, so you can confirm if the statement actually did something, such as insert, update, or delete. And ExecuteScalar returns a single value, such as a COUNT(*) or a single column with a query you know will return only a single record. 
  
 David, what you said makes sense.  Although depending on what you’re filtering on, it can still be a view.  We have a view that retrieves the current date and filters out records that have a date older than the current date, so it’s dynamic but based on a SQL Server function.  But if it’s a user-supplied value, then definitely the WHERECLAUSE is a way to go.  We are fairly new to SQL Server and none of us are DB whizzes so we haven’t gotten involved much with creating our own stored procedures yet. 
  
 Allen

Hi Allen,  
  
 Thanks for adding that information, I was a bit succinct in my description. :)