You don't stop puzzling me
stanlyn said:
Yes they are extremely busy with inserts and updates. It is also a dev server, not production.
Are you saying your dev server is busy?
Let me get back a bit:
Stanlyn said:
I have to do a query to get this value, hence the select statement as it is not a known value that can be set literally.
I hought so. Initially I thought you had a libsort value at hand to begin with. You will have it, after the first run.
Stynlyn said:
What I initially thought your script was doing was building it into the main select as a subquery.
It is.
Stynlyn said:
But I see now that you are wanting me to set it to 'something' without querying for it. The only 2 values that are known are @cImagePath and SystemId.
What? Where is there a set statement. The subquery is just substituted for the value, there is no SET, there is a > comparison with it's result. The subquery result is goping straight into the comparison without first setting a variable.
Stynlyn said:
The only 2 values that are known are @cImagePath and @SystemId.
Well, then you better integrate this. But in the end, I don't see why you feed in @cImagePath and @SystemId into a stored proc (I imagine you later turn tis into a parameterized stored proc), then finally don'T return the ImagePath and SystemId characterizing the next page. If you feed in the same initial values your nextpage function is not a next page function, fetch page n and get page n+1 function, finally a get page n+1 function, so you never get page n+2.
Your overall logic is flawn, if this isn't just for testing purposes, you showed the result value for libsort, so you could write it into a script. Again this would only fetch a certain next page. But you can store the libsort value somewhere, can't you? Memory variable, temp table, whatever, and then you can feed this into a next page or also previous page function. These page flip function onyl would need the last query and whatever you do to get an inital libsort value would be part of another subroutine.
If you instead intend to always only feed in a certain pair of values @cImagePath and @SystemId you better have one query. Find out what the deadlock problem is. I am quite convinced about more complex queries. It's not shorter code, that makes code run faster, its giving the possibility to the sql engine to better optimize your overal goal. Doing two queries compares to a case where someone posts a question, get's an answer, posts the next question, and then the expert says: Why didn't you tell in the first place? There is an overall much simpler solution! This specific case and the deadlocks "prove" me wrong, but in general that's true, sql server is quite good at optimizing.
Take a simple case, instead of
[tt]SELET TOP 1 * FROM sometable ORDER BY somefield[/tt] you do
[tt]SELET TOP 1 * FROM sometable ORDER BY somefield[/tt] and only use the first result row. Well, then sql server has to fetch the whole table in the wanted order. When you tell you just want the top 1 record that enables sql to look up the min value in an index and only fetch that single record. It will not sort all data in memory and then return the first row, it will only determine the first row. It will not just use the index on the field to sort faster, it uses it to look up the min value. And how would it do TOP N? Well, start with the top and then traverse the index in index order...
And in general splitting a complexer query into two smaller is only good for your better readability and maintainance, it's not good for MSSQL, unless you reach a point you clearly can optimize a partial query better or the partial queries are reusable and can be put together in other ways. In the end an applicatrion is having many different tasks and the goal never is to put all takss into one giant query capable to answering any request you may think of. Rule: No god class - same goes for SQL with queries. It's a matter of experience to know the granularity level of queries making sense. Too complex is as bad as too atomic.
Your query complexity is not that high, that you better explain it to the machine in two smaller tasks, I don't know what's hindering it to simply give a result in split seconds, as you say you have an index on lib_sort. Do you have no index on image_path and system_id? Anyway, as you can really store libsort somewhere - it's not that users have to enter it - you can just do the second query and have another routine finding a certain start page. Wouldn't that solve your problem?
Are we not actually finished with this problem, or is there still a problem left open? I can't help you with analyzing the deadlock from far away, I still don't know whether you want to be able to page forward with the two parameters also for the next page after the next page, but I do know you could solve that by working with the direct lib_sort value you know from the first call and then only need the simple secondary query. For that reason a split into two procedures would solve it, wouldn't it? You might even have a second third, fourth way to determine some starting point lib_sort value, but after that only need next/previous page code working with just the lib_sort column and index, right?
Bye, Olaf.