This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, I have a data model that has an Account table and a Person table. Person Table has a foreign key to account table. An account table can have multiple persons of different types associated with it.
For example Types like Account holder, co owner(s), heir(s)
Everything works great and no performance issues.
I have a search screen which has search fields like Account #, setup date range, Account Holder Name (first, last, business) , co owner name (first, last, business), status and many other fields.
The search returns list of custom object which gets displayed in the grid.
The performance is not good. For a simple query lets say account number or status the query is fine but creating the custom list for 143 records takes 15 secs… which is unacceptable.
I was thinking is this a good place to use a store procedure. We only have 4 search screens like this.
I was already planning to use store procedures for the reports (20 reports).
I have never used stored procedure on Lightspeed. I want to know if this is the time to use a store proc or optimize my linq for better performance.
Thanks, Sadia
|
|
|
Hi Sadia, Thanks for your query. This could very well be a location to use a stored procedure as it will provide the most refined mechanism for you to tune the query yourself. We have a screencast on stored procedures here: http://www.mindscape.co.nz/products/lightspeed/screencasts/storedprocedures.aspx If you have the time, could you please fire through your query and model files via email (jd@mindscape.co.nz) I'd be interested in having a look just to ensure there's not something we're doing that's causing the performance hit. I hope that helps, John-Daniel Trask |
|