HammerDB not saving/using password

[simonhTDN]

Hi All,

We're having an issue getting HammerDB setup. Each time we try to set the password, we're met with this "mssqls_pass" error, and no matter what we try it's acting like it's not being given a password. We've removed all special characters, set it in the config file, tried using the installer instead of the zip file, and we've even gone as far as temporarily disabling Windows defender. Nothing so far is working and we need some help figuring this out.

Please find the error log below, any help would be greatly appreciated.

loading history file ... 0 events added
Main console display active (Tcl8.6.12 / Tk8.6.12)
Unmatched Background Error - can't read "mssqls_pass": no such variable while executing ".ed_mainFrame.mainwin.textFrame.left.text fastinsert end "#!/usr/local/bin/tclsh8.6
#EDITABLE OPTIONS#################################################..."
    (procedure "loadmssqlstpcc" line 22)
    invoked from within
"loadmssqlstpcc"
    ("eval" body line 1)
    invoked from within
"eval $command"
    (procedure "loadtpcc" line 15)
    invoked from within
"loadtpcc"
    invoked from within
".tpc.b1 invoke "
    invoked from within
".tpc.b1 instate !disabled { .tpc.b1 invoke } "
    invoked from within
".tpc.b1 instate pressed { .tpc.b1 state !pressed; .tpc.b1 instate !disabled { .tpc.b1 invoke } } "
    (command bound to event)
(HammerDB-4.5) 1 % 

[sm-shaw]

Hi,
This sounds like a bug, in v4.5 there is dynamic storage of the variables in SQlite dbs #336 so now if there are no SQLite dbs to store the configuration then the values are picked up from the XML config otherwise the last stored value is set in the corresponding SQLite database and these are used. The error is coming from loading the test driver script, so the first thing to try is to try loading the timed driver script instead - if it errors here as well then the error is in the XML/SQLite db configuration.
After this try clearing the SQLite dbs by removing them when HammerDB is stopped. By default they are stored in the users TEMP area and have names such as mssqlserver.db - all they store is the current configuration so try deleting them and restart HammerDB and it will recreate the dbs from the XML again. It is possible that something got corrupted in the value stored in the db as the error means that the mssqls_pass value is not being picked up - possibly due to special characters? Another way to troubleshoot is to run the CLI and do "dbset db mssqls" and print dict to see what is stored in the password field.
The error is nothing to do with Windows defender.

[simonhTDN]

Hi, This sounds like a bug, in v4.5 there is dynamic storage of the variables in SQlite dbs #336 so now if there are no SQLite dbs to store the configuration then the values are picked up from the XML config otherwise the last stored value is set in the corresponding SQLite database and these are used. The error is coming from loading the test driver script, so the first thing to try is to try loading the timed driver script instead - if it errors here as well then the error is in the XML/SQLite db configuration. After this try clearing the SQLite dbs by removing them when HammerDB is stopped. By default they are stored in the users TEMP area and have names such as mssqlserver.db - all they store is the current configuration so try deleting them and restart HammerDB and it will recreate the dbs from the XML again. It is possible that something got corrupted in the value stored in the db as the error means that the mssqls_pass value is not being picked up - possibly due to special characters? Another way to troubleshoot is to run the CLI and do "dbset db mssqls" and print dict to see what is stored in the password field. The error is nothing to do with Windows defender.

Thank you for the reply. I'll try out your suggestions, I only mention Windows Defender as it flagged several files contained within the HammerDB zip when I tried to verify dependencies, and it then quarantined them. We created a test account with a password containing no special characters, thinking that might be the issue but the behaviour was the same. I should note, the only time we are able to get it working properly, is by running it after the successful install from the .exe package as opposed to the zip file.

[sm-shaw]

Many thanks for the update and the correction, perhaps this quaranting may have something to do with it as it is not something observed during testing.
Once it is successfully installed from the .exe does it run correctly all of the time or only the first time i.e. when it has read the configuration from the XML on first install rather than the SQLite dbs.
This will be rechecked as the first step will be to try to reproduce the behaviour - can you also please advise on the version of Windows being used.

[simonhTDN]

It only ever works the one time following the installation launch. After that it will continue to have the same password error. It was being ran on Windows Server 2022 Standard (10.0.20348)

[sm-shaw]

Many thanks for the quick update. That does sound like an issue with the new SQLite storage. And this also only occurs with a password with special characters or with any password? and for both test and timed scripts.
If just with special characters please advise which characters are in the password to reproduce.

[simonhTDN]

This is with any password, at first we had one with special characters but then moved to creating an entirely new SQL account with a standard alphanumeric password which failed in the same way.

[sm-shaw]

Thanks, it would be great if you can confirm that removing the ".db" files in the temp area, temporarily resolves the issue on restart. I was sure that it wasn't to do with Windows defender, however now I am not so sure and wondering whether something is preventing the data being stored correctly so will need to try and reproduce.

[sm-shaw]

As a first step, I've confirmed that the contents of the zip and installer are the same and there are no packaging errors with the only difference being the uninstaller for the installer package.

$ diff -r HammerDB-4.5-EXE HammerDB-4.5-ZIP
Only in HammerDB-4.5-EXE: uninstall.dat
Only in HammerDB-4.5-EXE: uninstall.exe

I've then set a password for the sa user as shown

and this runs correctly (test script example)

I've also verified that setting an incorrect password prevents logging in so the password is being used

Error in Virtual User 2: Connection to DRIVER=ODBC Driver 17 for SQL Server;SERVER=(local)\SQLDEVELOP;UID=sa;PWD=SQLServe could not be established : [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Login failed for user 'sa'.
(connecting to database)

print dict in the CLI shows the correct password

hammerdb>print dict
Dictionary Settings for MSSQLServer
connection {
 mssqls_server         = (local)\SQLDEVELOP
 mssqls_linux_server   = localhost
 mssqls_tcp            = false
 mssqls_port           = 1433
 mssqls_azure          = false
 mssqls_authentication = sql
 mssqls_linux_authent  = sql
 mssqls_odbc_driver    = ODBC Driver 17 for SQL Server
 mssqls_linux_odbc     = ODBC Driver 17 for SQL Server
 mssqls_uid            = sa
 mssqls_pass           = SQLServer
}

and also direct query of the SQLite storage shows that the value is correctly stored

% package require sqlite3
3.36.0
% sqlite3 test {C:\Users\Steve\AppData\Local\Temp\mssqlserver.db}
% test eval "pragma table_info(connection)"
0 key TEXT 0 {} 0 1 val TEXT 0 {} 0
% test eval {select val from connection where key = 'mssqls_pass'}
SQLServer
%

So far it has not been possible to reproduce the error.

[sm-shaw]

To permit further investigation, please try the following tests. Firstly, in the bin directory, click on tclsh86t and run the following to query and manually update the SQLite storage. Change the database name to the location of where yours is stored.

Once updated, use the CLI to show the database changes.

if this doesn't work for you, it is possible that something is blocking the correct use of SQLite in your configuration.

[simonhTDN]

Looks like we're up and running for the time being. I'll let you know if anything changes, really appreciate the assistance.

[sm-shaw]

Closed as not a bug.