Implementation of RunSolveAlgorithm4:
This is the last post in this series. The previous algorithm is the last one that tries to solve the puzzle logically. This one will take the latest unsolved sudoku board that we get after running through the first three algorithms and use brute force to solve the puzzle. I am not going to reinvent the wheel here.
Implementation of RunSolveAlgorithm3:
The last algorithm that we implemented was able to solve an easy puzzle. Now, lets take a hard one and see if the solution we have built till now in this series can solve it.
EXEC SolveSudoku
'030,001,000,,006,000,050,,500,000,983,,080,006,302,,000,050,000,,903,800,060,,714,000,009,,020,000,800,,000,400,030'
Implementation of RunSolveAlgorithm2:
We implemented RunSolveAlgorithm1 in previous post of this series . The next algorithm is the implementation of Solve Method A from sudoku solver.
In this algorithm, we check all the cells (having mutiple values) in each row and see if a particular value occurs only once in that row. Then update that as the solution for the cell having that value. We do the similar check for column and the 3X3 block.
Implementation of RunSolveAlgorithm1:
In the previous post of this series, we created the procedure stub for each algorithm. This post will implement RunSolveAlgorithm1.
The first algorithm will do the primary clean up on the solution board. It will implement the basic rules of Sudoku. The rule is that a number cannot appear in a cell if it already appears in any other cell in the same row or column or the block in the sudoku board. It will remove those numbers from the possible cadidate values of each cell in the solution board.
In the first part of this series, we created the base objects needed to work on our solution. Now, there are two parts to building the solution:
This one is going to be a series. I thought I was going to come up with a single query to solve Sudoku (without choosing the brute force method). When I started creating the tables I needed, I figured out there there are way too many aspects to solving Sudoku logically. I thought it would be a good idea to give a continous update as I go about building the solution.
This post is all about creating the necessary tables and basic procedures which I think we need to build the solution.
In this post, I have attempted a crude implementation of Object Oriented SQL Programming using the APPLY operator in SQL Server 2005. I feel that giving some thought in these lines, we can bring in more flexibility, abstraction and reusability to the way we query the database and, may be, create a new style for data access.
There is only one rule that I am going to follow here. All table access will be done using an INLINE TABLE VALUED function. No query will directly access the table. I would like to illustrate it with a small example.
I guess, by now, most of you are familiar with the SQL Server 2005 sample database - AdventureWorks. We will use one of the tables from this database to create our scenario - Production.BillOfMaterials. To simplify our requirements, we will be selecting only those records in this table, that has the EndDate as NULL.
Posts
All Comments
