![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 7 of 7 total |
![]() |
Mon, Apr 9 2007 10:22 PM | Permanent Link |
"Ole Willy Tuv" | Tim,
I've translated the EDB version of the Sudoko database from a Transact-SQL script. The Sudoko table has 81 rows representing the 9x9 Sudoko matrix. The sp_default_Sudoko_puzzle procedure sets cellValue column with default values in 25 rows and null in the remaining 56 rows. The sp_solve_Sudoko_puzzle procedure, when working correctly, should resolve the remaining 56 cellValue values. Using the sp_Sudoko_debug3 version, the sp_solve_puzzle procedure only resolves 25 of the 56 values. I've executed the two queries in the SolveSingleCells manually and updated the Sudoko table with the results. The results are correct for the 2-3 first iterations (verified by checking SQL Server results), but then the results are getting wrong. There are a bunch of utility views used by the two queries in the SolveSingleCells procedure, some with joins and unions, and I suspect that there can be a problem with some of these in EDB (I've implemented workarounds for the grouping and union issues I've reported). The underlying queries seem to be equivalent to the Transact-SQL versions, and they all returns the same results as SQL Server at the time the default Sudoko puzzle is set and also during the first few updates done by the SolveSingleCells procedure. I'll do some more debugging as time allows. Ole Willy Tuv |
Tue, Apr 10 2007 9:16 PM | Permanent Link |
"Ole Willy Tuv" | Further checking - I've translated the EDB version to a NexusDB script, such
that the table and view definitions are exactly the same. I'm getting the correct results with NexusDB (as with SQL Server), indicating that the incorrect results with EDB 1.02 are EDB issues. Ole Willy Tuv |
Wed, Apr 11 2007 5:16 AM | Permanent Link |
"Uffe Kousgaard" | "Ole Willy Tuv" <owtuv@online.no> wrote in message
news:3349B9EE-FDA0-42B6-B233-A3B9156B5437@news.elevatesoft.com... > > The sp_solve_Sudoko_puzzle procedure, when working correctly, should > resolve the remaining 56 cellValue values. Are you using SQL to solve sudoko? Or is it stored procedures? |
Wed, Apr 11 2007 6:42 AM | Permanent Link |
"Ole Willy Tuv" | Uffe,
<< Are you using SQL to solve sudoko? >> The Sudoko database implements algorithms to solve 9x9 Sudoko puzzles. I've translated the EDB version from a Transact-SQL script. The purpose was to test the PSM stuff in EDB and as you can see from my other, the Sudoko SQL has revealed a few bugs. << Or is it stored procedures? >> The database creation script is coded as a stored procedure, which is the only option EDB currently supports. The Sudoko database contains stored procedures to set a default puzzle, clear the current puzzle, update the Sudoko tables and solve the current puzzle. Ole Willy Tuv |
Wed, Apr 11 2007 8:31 AM | Permanent Link |
"Ole Willy Tuv" | Tim,
I'm enclosing the latest debug version of the Sudoko database (sp_Sudoko_EDB_debug4.sql). Here's how the "iterations" table look like after executing the sp_solve_Sudoko_puzzle on the default puzzle: iteration query rowID columnID cellValue sudoko_rows --------------------------------------------------------- 1 Q1 6 9 9 26 1 Q2 3 2 7 27 1 Q2 3 9 1 28 1 Q2 5 4 4 29 1 Q2 6 6 6 30 1 Q2 8 1 4 31 1 Q2 8 7 7 32 --------------------------------------------------------- 2 Q1 6 7 2 33 2 Q2 3 7 8 34 2 Q2 4 9 4 35 2 Q2 6 4 7 36 2 Q2 9 5 7 37 --------------------------------------------------------- 3 Q1 2 4 3 38 3 Q1 5 7 3 39 3 Q2 2 6 7 40 3 Q2 5 7 3 40 3 Q2 7 7 4 41 --------------------------------------------------------- 4 Q1 8 4 8 42 4 Q2 3 8 3 43 4 Q2 8 6 3 44 --------------------------------------------------------- 5 Q1 7 4 2 45 5 Q1 8 9 5 46 5 Q2 2 8 5 47 5 Q2 9 9 3 48 --------------------------------------------------------- 6 Q1 7 9 8 49 6 Q2 7 9 8 49 6 Q2 9 8 2 50 --------------------------------------------------------- The procedure updates 25 Sudoko rows, while the correct/expected result is 56 rows such that the Sudoko table should have valid cellValue values in all 81 rows. Here's the "iterations" table after executing the same procedure with the SQL Server and NexusDB versions: iteration query rowID columnID cellValue sudoko_rows --------------------------------------------------------- 1 Q1 6 9 9 26 1 Q2 3 2 7 27 1 Q2 3 9 1 28 1 Q2 5 4 4 29 1 Q2 6 6 6 30 1 Q2 8 1 4 31 1 Q2 8 7 7 32 --------------------------------------------------------- 2 Q1 6 7 2 33 2 Q2 3 7 8 34 2 Q2 4 9 4 35 2 Q2 6 4 7 36 2 Q2 9 5 7 37 --------------------------------------------------------- 3 Q1 2 4 3 38 3 Q1 5 7 3 39 3 Q2 2 6 7 40 3 Q2 3 8 3 41 3 Q2 7 7 4 42 3 Q2 8 6 3 43 --------------------------------------------------------- 4 Q1 5 6 5 44 4 Q1 8 4 8 45 4 Q1 9 9 3 46 4 Q2 2 8 5 47 4 Q2 7 9 8 48 --------------------------------------------------------- 5 Q1 7 4 2 49 5 Q1 7 6 1 50 5 Q1 8 9 5 51 5 Q2 7 5 5 52 5 Q2 8 2 1 53 5 Q2 9 8 2 54 --------------------------------------------------------- 6 Q1 6 2 5 55 6 Q1 8 5 6 56 6 Q2 6 1 1 57 6 Q2 7 3 9 58 6 Q2 7 8 6 59 --------------------------------------------------------- 7 Q1 3 3 5 60 7 Q1 8 8 9 61 7 Q1 9 2 8 62 7 Q2 4 3 8 63 7 Q2 9 1 5 64 --------------------------------------------------------- 8 Q1 4 1 3 65 8 Q1 5 5 8 66 8 Q1 9 3 6 67 8 Q2 1 1 6 68 8 Q2 1 3 3 69 --------------------------------------------------------- 9 Q1 1 7 9 70 9 Q1 2 3 1 71 9 Q2 1 5 1 72 9 Q2 2 7 6 73 9 Q2 3 1 9 74 --------------------------------------------------------- 10 Q1 1 2 2 75 10 Q1 2 5 9 76 10 Q1 3 6 2 77 10 Q1 5 1 2 78 10 Q2 4 5 2 79 10 Q2 4 6 9 80 10 Q2 5 2 9 81 --------------------------------------------------------- Now that you know the correct result, you could check the EDB result after you've implemented bug fixes for the reported issues. Ole Willy Tuv Attachments: sp_Sudoko_EDB_debug4.zip |
Thu, Apr 26 2007 3:13 PM | Permanent Link |
"Ole Willy Tuv" | An update on the Sudoko issues:
Tim has now fixed the issue with static views not refreshing properly. This means that cursors are now working as expected in EDB, regardless of the underlying data source. The issue with calling a procedure without a parameter list not working is also fixed. My EDB version of the Sudoko SQL solver is now working like a charm, and I'll post the final version of the Sudoko database script here when EDB 1.03 is out. Excellent job, Tim! Ole Willy Tuv |
Thu, Apr 26 2007 3:22 PM | Permanent Link |
"Ole Willy Tuv" | << My EDB version of the Sudoko SQL solver is now working like a charm >>
I forgot to mention that the EDB version is 3 times faster than the equivalent SQL Server version (using cursors for grabbing the update values), and at least as fast as the original SQL Server version (using derived tables in queries and the UPDATE FROM syntax for updating the Sudoko table). Ole Willy Tuv |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |