Background
FastTrak is normally set up to use integrated security when connecting to the database. To use the application, every user must have his own user account in the sys.sysusers table. The users in sysusers will have a user name matching the domain user, and a security identifier (SID).
Occasionally, a domain user is deleted and recreated. This will cause the SID to change, and the SID of the database user no longer matches the SID of the recreated domain user. The user may still be able to connect to the database via a group login, but will be connected as public. This means that the USER_ID() function in the database will return 0 for that user. The application will complain that the users doesn't have a user account, and will shut down.
Workaround
The solution is to revoke access to the database, and then grant it again, using a script like this:
EXEC sp_revokedbaccess 'ADM1\ab123'
GO
EXEC sp_grantdbaccess 'ADM1\ab123'
GO
The new user created should keep the USER_ID() of the old user, and the new user is matched to the recreated domain user. One may be tempted to use this stored procedure to solve the problem:
EXEC sp_change_users_login 'AutoFix', 'ADM1\ab123'
but this will not work. See also a relevant chapter in the user documentation, "Hvis pålogging feiler".
Affected versions
All database versions have this potential problem, as it is a property of MS SQL Server and Active Directory security.
