The Changed by column in the Commit Tab might list objects as changed by Unknown:
You can still commit the change to source control as normal, as the "Changed by" information is never committed to source control anyway.
SQL Source Control can't tell who made changes to data, or to the following object types:
full text catalogs
full text stoplists
search property lists
user-defined data types
user-defined table types
By default, SQL Source Control reads information about who made changes from the default trace and saves it in tempdb. However, because tempdb is reset when the server is restarted, information about who made a change is eventually lost.
To stop the information being lost, you can create a database to log changes instead of tempdb.
If you update to a new version of SQL Source Control while there are uncommitted changes, information about who made changes might be lost.
When an object is renamed, information about who renamed it is lost.
This is because SQL Source Control reads information about who made a change from the default trace. In the case of a rename, the default trace records the activity correctly as a rename. However, SQL Source Control interprets the action only as a drop and create, and so can't find the relevant information in the default trace.
When SQL Source Control checks the database for changes, it reads information about who made a change from the default trace and saves it in tempdb. If you're working with a busy server, the default trace can fill up and roll over before SQL Source Control can read it. Information about who made changes is lost.
To improve the chances of the default trace being read before it rolls over, you can set the change indicators to update more frequently in the Setup tab. However, this might slow down your server.
As of version 6.0.3, you can also configure SQL Source Control to read from the rolled over trace files. This may reduce the incidence of changes showing as made by 'unknown' users, but will also have a slight performance impact on SQL Server.
To enable this option:
%localappdata%\Red Gate\SQL Source Control 7\RedGate_SQLSourceControl_Engine_EngineOptions.xml, in a text editor
<EngineOptions version=... line
Below that line, add
When SQL Source Control checks the database for changes, it reads information about who made a change from the default trace. If the default trace isn't enabled for the server, information about who made the change is lost.
To enable the default trace, run this SQL:
When SQL Source Control checks the database for changes, it reads information about who made a change from the default trace. If you don't have the correct permissions to access the default trace, information about who made the change is lost.
Users need the ALTER TRACE and VIEW SERVER STATE permissions to access the default trace. To add these permissions, your system administrator needs to go to each user's login (Security > Logins on the server level) and enable them under Securables.
If you are using the default Changelog database, you will also need EXECUTE and ALTER permissions on tempdb. Without those permissions, SQL Source Control may still show a warning on the commit page that you don't have access to the default trace.
For more information about the default trace, see The default trace in SQL Server - the power of performance and security auditing on Simple Talk.
If the server takes too long to respond, SQL Source Control can't tell who changed any objects. When this happens, SQL Source Control displays a warning bar above the change list:
Unlike other causes of the "Unknown" problem, missing information caused by a server timeout isn't lost permanently. To see who changed the object, try refreshing the change list when the server is less busy.