The main use of this tool is to attach to any ODBC data source and let you browse and run SQL commands. Steve found that it had an option to OPEN a text file containing SQL commands. So, when he got an ASQL syntax error, he started WinSQL and had it open a file that ASQL automatically created. The file contained the SQL that ASQL generated. When the SQL from this file was loaded into WinSQL, it syntax highlighted the exact syntax error and I think have a message about what was wrong with the offending syntax.

The really cool part was that Steve was able to fix the syntax in WinSQL and have WinSQL execute the create table as modified. Then the table worked with APPX in it's modified fashion without having the change the offending field name in the APPX database.

This was a great debugging tool. And also a great tool to correct errors in field names without having to change the APPX data file and field names. AppxODBC does not match up by field name, so this worked.

WinSQL is also useful for debugging our SQL Server (via ODBC) connection (www.appx.com/pub/documents/odbc.ConnectionInstructions.txt).

There are many protocols SQL Server can use. (TCP/IP, named pipes, LocalServer, ...) The client (the ODBC data source) and the server must be speaking the same protocol.

WinSQL is good at passing through error messages that our APPX/ODBC connection might filter out. Thus, it's a good debugging tool if you're unable to get APPX for Windows to talk successfully to an ODBC / SQL Server backend to APPX.

Sometimes, you can get APPX/ODBC connection working over 'LocalServer' DSN, where it might not work properly with a manually created DSN. This could be because Local Server uses a simple protocol. Client & server know automatically which to use.

(Under ODBC , you have to have a listener set up for each protocol. The client has to know which protocol, plus addressing and identification info. For example, you may have to have a TCP/IP listener (with IP address & port#).)