Especially for Windows XP machines after Service Pack 2 (SP2) is installed some WMI related problems can occur due to security updates included in sp2. These problems cause PragmaSQL not to perform license check correctly and as a result application does can not start. Some probable solutions to this WMI related problem are

Probable Solution - 1: Please ensure that Windows Menegement Instrumentation service is not disabled

Probable Solution - 2:  Try running this command and see if it works
netsh firewall set service type=remoteadmin mode=enable scope=all profile=all

Probable Solution - 3:   Follow these steps

1. Use the Start menu to right-click My Computer.
2. Press the Manage item.
3. Double-click Services and Applications in the left-hand pane.
4. Press Services to expand it.
5. Scroll to Windows Management Instrumentation in the right-hand pane and right-click it.
6. Press Stop.
7. Use Windows Explorer to delete all the files in the %SystemRoot%\System32\Wbem\Repository folder.
8. Shutdown and restart your computer. The Windows Management Instrumentation service will start and the files will be re-created.

Probable Solution - 4: Go to Start/Run/CMD and then run each of these hitting enter after each:

1. winmgmt /clearadap
2. winmgmt /kill
3. winmgmt /unregserver
4. winmgmt /regserver
5. winmgmt /resyncperf

Probable Solution - 5:   To correct permission issues:

1. In the Management Console\Services STOP WMI and set to manual.
2. Go to the WMI repository %Windows%system32%wbem and delete the repository.
3. Set the WMI service back to Automatic
4. From %Windows%system32%wbem run "wbemtest" and connect to your namespace.
5. Start/Run/Regedit and navigate to: Locate current HKEY_CURRENT_CONFIG\System\CurrentControlSet\Control\Class. Open the class key and right click on the sub key 0000 and select permissions and make sure that the permissions for you [administrator] are "Full".

Some PragmaSQL users were notifying me about a strange but deadly serious error caused after recovering from a server connection transport-level error. To reproduce the error follow these steps:

1- Open PragmaSQL Editor and choose a connection from Saved Connections list to connect. I will assume that Default Database of the selected connection is DatabaseA 

2- In the opened script editor change database to DatabaseB

3- Open to Microsoft Sql Server Management Studio and from Management node select Activity Monitor. Find the process for DatabaseB created by PragmaSQL application and kill that process.

4- Return to PragmaSQL editor and try to execute the select statement for the selected database, that is DatabaseB.

5- You will get transport-level error after trying to execute the statement for the first time.

6- Try to execute the statement again and this time you will succeed. But the statement was executed on the initial database, that is DatabaseA not in DatabaseB (selected one ). This error may cause very serious problems if you were trying to modify data you would simply modify the data in wrong database.

The problem is actually with database change code inside PragmaSQL which is not really a bug but misusage of SqlConnection class's ChangeDatabase method. While I was coding the change database logic I did not realy realised that ChangeDatabase method does not modify the Initial Catalog property of the ConnectionString, actually there is no way to modify the ConnectionString property of the SqlConnection object once it is opened. SqlConnection object in the script editor is created and opened only after the user changes the selected server, database changes does not cause a new SqlConnection object to be created and opened, we simply change the database property of the existing SqlConnection object and that is it. I did not considered SqlConnection object's error recovery scnearios (transport-level error for example) at all. The fact is that SqlConnection class recovers from transport-level error very well but uses the ConnectionString property to reopen the connection, no matter what was the database before the error SqlConnection object always restores connection to Initial Catalog property specified in the ConnectionString.

Very ugly bug, but I am happy to resolve that one. Upcoming 1.0.0.34 version will include solution for this issue.