Your schema change is blocked, and the error is telling you why

You need to widen a column. It was `varchar(20)` and the business has outgrown it. You write the `ALTER TABLE`, run it, and SQL Server refuses:

Msg 5074, Level 16, State 1
The index 'IX_Barcode' is dependent on column 'UIDBC'.

Msg 4922, Level 16, State 0
ALTER TABLE ALTER COLUMN UIDBC failed because one or more
objects access this column.

The tempting move is to drop the index, run the alter, and put the index back. Sometimes that is exactly right. But the error is worth reading properly first, because it is not an obstacle — it is the only free warning you are going to get that other objects depend on this column, and one of them may care about its type in a way an index does not.

Find everything, not just the thing that complained

SQL Server reports the first blocking dependency, not all of them. Fix that one and it will report the next. Before touching anything, get the full picture:

-- Objects referencing the column by name
SELECT DISTINCT o.name, o.type_desc
FROM   sys.sql_expression_dependencies d
JOIN   sys.objects o ON o.object_id = d.referencing_id
WHERE  d.referenced_entity_name = 'YourTable'
  AND  d.referenced_minor_name  = 'UIDBC';

-- Indexes that include it, as key or as included column
SELECT i.name AS index_name, i.type_desc, ic.is_included_column
FROM   sys.indexes i
JOIN   sys.index_columns ic
       ON ic.object_id = i.object_id AND ic.index_id = i.index_id
JOIN   sys.columns c
       ON c.object_id = ic.object_id AND c.column_id = ic.column_id
WHERE  i.object_id = OBJECT_ID('YourTable')
  AND  c.name = 'UIDBC';

Then check the things the catalogue views will not tell you: foreign keys pointing at the column, check constraints, computed columns derived from it, and — the one that bites — any dynamic SQL that builds a query string at runtime. Dependency tracking cannot see inside a string.

The dependency you actually care about

An index is easy. Drop, alter, recreate. The dangerous dependency is the one that quietly relies on the current type. A view that joins this column to a `bigint` somewhere else has been getting an implicit conversion for years. Widen the type and the conversion changes; the join may still work and simply return different rows.

The change that fails loudly is cheap. The change that succeeds and quietly returns different numbers is the one that costs you a month.

This is why the sequence matters more than the syntax. Identify the column. Find every index. Find every view, procedure, function and constraint. Assess compatibility for each — not "will it still run" but "will it still mean the same thing". Plan the change. Modify the dependencies. Alter the schema. Then validate.

Validation is the step people skip

Before the change, capture the numbers that must not move: row counts, distinct counts on the affected column, and the business totals that any downstream report produces. After the change, run them again and compare. If a total moved, you have learned something important while you can still roll back.

-- Capture before, compare after. Cheap insurance.
SELECT COUNT(*)              AS row_count,
       COUNT(DISTINCT UIDBC) AS distinct_uid,
       SUM(CAST(Marks AS decimal(18,2))) AS total_marks
FROM   YourTable;

On a production database that cannot be taken offline, plan the window around the operational cycle rather than the other way around, and keep the rollback path — the original index definitions, scripted — in the same file as the change. If you cannot state how you would undo it, you are not ready to run it.

The short version

• The error names one dependency. Go find the rest before you start.
• Indexes are the easy case. Views and procedures relying on an implicit conversion are the expensive one.
• Ask whether each dependent object will still mean the same thing, not just whether it will still run.
• Capture counts and business totals before; compare after.
• Script the rollback in the same file as the change.