Hi Beth,
There has not been a release of 2.3.8.3. A release is when I compile a build and make anew package of pre-compiled files for people to download. The source code repository is always the latest code, the version number corresponds only to changes int the database schema, ie new upgrade scripts are added with incremented versions every time I need to make any changes in the database. So currently in the repository the database is up to script 2.3.8.3 but other changes will be made before the next official release is packaged, amd possibly I will even need to make additioanl changes in the database and increment the upgrade script again before the next official release. But if you are using the latest code you should see the version as 2.3.8.3 since that is the most recent upgrade script in the repository.
Of course there will be errors expected if you run the latest code without running the upgrade scripts. New fields like "RolesChanged" get added by upgrade scripts and the newest code expects the new field, so the code and the database have to be in sync and that is what the setup page does it runs the scripts to upgrade the database to get it in sync with the latest code.
I'm not really sure what is going on, hashed password don't depend on the machine key so that isn't a factor.
My password is correct but the hash doesn't exist in the db at all.
What do you mean by that? Your password is correct where? in the database?
If using hashed passwords you will not see the password in the database you will only see the hash. The password field in the database is pwd not Password in case that is throwing you off. The Password field is a legacy field (no longer used) it was too small for the stronger hashing and stronger encryption so we migrated quite a while back from the Password field to a larger field Pwd. That change of fields was many versions ago, but we finally took advantage of the larger field in 2.3.8.1 when we implemented the stronger hashing.
The way it works with hashed password is the password you enter on the login page is concatenated with the value from the Password salt field then hashed and then the hash is compared to the hash in the pwd field, if it matches the password is correct.
We changed from MD5 hash with no salt to SHA512 hash with salt. Salt is just a random string concatenated with the password before hashing, it is stored in the PasswordSalt field. Its purpose is so that people who happen to use the same password don't have the same hash.
So when you try to login it is first trying to use the sha512 hash but if that fails it falls back to trying the old md5 hash (with no salt) so that it won't break any logins during upgrade. So I don't see how the change to stronger hashing could posisbly cause a login failure. Something else is going on here but I'm not really sure without being able to debug it myself.
If you want to email me a database backup and tell me a user name and password that should work I could try to debug it for you tomorrow, but I understand if you don't want to do that for data security reasons.
Best,
Joe