One difference between OBJECT_ID() and OBJECT_NAME() in SQL Server is the syntax used for cross-database queries. By this I mean, when they’re used on objects in a different database.

The OBJECT_NAME() function has an optional argument that you can provide, which specifies the database ID of the database that contains the object you’re trying to get the name of. Providing this argument enables you to get the name of an object on a different database.

The OBJECT_ID() function on the other hand, doesn’t require such an argument. Instead, this function allows you to use a 3-part name to specify the database, schema, and name of the object that you’re trying to get the ID of.

This article contains examples of using OBJECT_ID() to get the name of an object from a different database.

Continue reading →

If you ever need to use the OBJECT_NAME() function to get an object’s name from a different database in SQL Server, you might run into issues if you don’t know how it works.

You probably know that OBJECT_NAME() accepts an object_id argument that tells SQL Server which object to get the name from.

What you may or may not know, is that this function also accepts an optional database_id argument that tells SQL Server which database the object_id belongs to.

By default, SQL Server assumes that object_id is in the context of the current database. In this case, a query that references an object_id in another database will return NULL or (even worse) incorrect results.

Continue reading →

When using SQL Server, if you ever find yourself about to do a join against the sys.objects system catalog view in order to get the name of an object, maybe stop and read this first.

Transact-SQL has a built-in function called OBJECT_NAME() that returns the name of an object, based on its ID.

In other words, if you have the object’s ID (for example, the object_id column), you can simply pass that ID to the OBJECT_NAME() function, and it will return the object’s name for you – no join required!

Continue reading →

SQL Server has a system stored procedure called sp_depends that returns information about dependencies between objects within the current database.

Microsoft has marked this stored procedure as deprecated, which means that it’s in maintenance mode and may be removed in a future version of SQL Server. You should avoid using sp_depends in new development work, and you should modify applications that currently use it to use either sys.dm_sql_referencing_entities() or sys.dm_sql_referenced_entities() instead (depending on whether you need referencing entities, or referenced entities to be returned.

Continue reading →

In SQL Server, the sys.dm_os_performance_counters system dynamic management view returns the performance counters maintained by the server.

One of the many things you can do with sys.dm_os_performance_counters is return a list of deprecated features in the current instance of SQL Server. You can also use this list to see how many times a deprecated feature has been used since SQL Server was started.

This is quite possibly the quickest way to find out if you’re using a deprecated feature in SQL Server.

The view returns a row per performance counter maintained by the server. The SQLServer:Deprecated Features object provides a counter to monitor the features designated as deprecated. It has a cntr_value column, which provides a usage count that lists the number of times the deprecated feature was encountered since SQL Server last started.

Therefore, by running a query against this view, we can return all deprecated features along with a count of how many times each one was encountered since SQL Server last started.

Continue reading →

In SQL Server, you can use the sys.dm_os_performance_counters system dynamic management view to return a list of the features designated as deprecated in the current instance of SQL Server.

To return just the deprecated features, filter the view to just the SQLServer:Deprecated Features object.

The view also includes a counter that lists the number of times each deprecated feature was encountered since SQL Server last started. This can be helpful for identifying whether or not your application is still using any deprecated features.

Running this on SQL Server requires VIEW SERVER STATE permission.

Continue reading →