• subscribe
November 20, 2001 12:00 AM

Matching Transactions

SQL Server Pro
InstantDoc ID #22956
Downloads
22956.zip

Variations
Note in Table 2's results that if a transaction in one table doesn't have a matching transaction in the other table, the transaction doesn't appear in the output because Listing 4's query uses an inner join. In the scenario my student presented, only matching transactions are required in the output. For a similar solution that returns nonmatches as well, you need to change the inner join to a full outer join. You also need to slightly revise the SELECT list and ORDER BY clause so that in case one of the tables has a row with no match in the other table, the result comes from the table that has the data. Listing 5 shows the revised query, whose output appears in Table 3.

Chronological positions are important in determining which transactions match, but this example doesn't require them to appear in the output. You can write a query that joins Trans1 and Trans2 based on matching account IDs, amounts, and chronological positions. You can write subqueries to calculate and compare the chronological positions in the JOIN condition, without needing to specify them in the SELECT list. For example, you can replace the query in Listing 4 with the query in Listing 6. They both provide the same result, but the query in Listing 6 doesn't refer to any views.

You don't really need to create views in this case because the query in Listing 6 refers directly to the base table. I compared the performance of the solutions in Listing 4 and Listing 6, and they perform exactly the same, so you can use the solution that you feel more comfortable with.

Not Finished Yet
In your work with SQL Server, you'll find many examples of problems that you can solve by using a set-based solution, even though the solution might not be obvious at first. If, when you face the type of problems I describe here and in "Sequential to Set-Based," you first think of using cursors, it's time for you to make the move to set-based thinking. A good place to start is to practice the techniques I've demonstrated.

But we're not finished yet. In my next column, I'll present a more complex example and show you how to provide a set-based solution for it.



ARTICLE TOOLS

Comments
  • Brigitte Arnett
    10 years ago
    Jan 03, 2002

    Ben,

    Your article is very interesting and I promised to myself to take time and digest the information you give in this article.
    I am struggling with a concurrency problem and am thinking about a solution that goes in the opposite direction of what your article recommends though, so I am wondering if I am going in the right direction.
    A developer in my shop wrote a stored procedure that is called by a lot of programs. When executed this stored procedure will select a set of rows with a status code set to 'Job pending' and a job category set to say 'Batch'. The stored procedure then updates this set with one update statement, changing the status code to 'Active' and the jobid field to a value. When there was only one job in the system, this worked fine. Now that we have lots of jobs running concurrently, calling this same stored procedure, jobs time out left and right.
    I am advising the developer to rethink his stored procedure, to update one row at a time, sort of like cursor based update, except that it should not be cursor based, we would not have resolved the concurrency problem, but based on a list that he would have extracted previously in a set based retrieval with nolock hint.
    Do you think this would be the way for me to go?

You must log on before posting a comment.

Are you a new visitor? Register Here