Object changed by Unknown
Published 16 July 2015
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.
The object type is unsupported
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
Information is lost from tempdb
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.
SQL Source Control was updated while there were uncommitted changes
If you update to a new version of SQL Source Control while there are uncommitted changes, information about who made changes might be lost.
The object was renamed
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.
The default trace rolled over before SQL Source Control could poll it
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:
- Edit the engine options config file,
%localappdata%\Red Gate\SQL Source Control 7\RedGate_SQLSourceControl_Engine_EngineOptions.xml, in a text editor
- Find the
<EngineOptions version=... line
Below that line, add
The default trace is disabled
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:
EXEC sp_configure 'show advanced options', 1 RECONFIGURE EXEC sp_configure 'default trace enabled', 1 RECONFIGURE
You don't have permission to access the default trace
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.
The server timed out
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.