Linked Server Error Msg 7356: Provider Metadata That Changed

A linked-server query can fail even when the remote rows are readable directly. Msg 7356 identifies a disagreement in the column metadata reported through the provider.

Read the Column Detail in Msg 7356

The error identifies the provider, linked server, and column whose metadata was inconsistent. It can describe a difference between compilation and execution, such as flags, length, or other column properties. Save the full message and the smallest failing statement. Do not reduce the incident to a vague report that the linked server stopped working.

A remote schema change is a useful starting hypothesis, but it is not the only possible cause. Provider behavior, a changed remote view, an expression's reported type, or different execution paths can expose inconsistent metadata. I compare the reported disagreement with the actual remote definition before choosing a workaround.

Run the remote statement directly under the relevant remote identity where permitted. Record the local engine build, provider version, remote definition, and recent deployment changes. A direct success narrows the problem; it does not prove that the provider can describe the same result consistently through the linked-server path.

Inventory the Linked Server and Its Options

The native linked-server procedure lists the registered server definitions and provider information. The catalog exposes additional server options. These read-only checks help establish which connection definition the failing query actually uses.

EXEC master.dbo.sp_linkedservers;
SELECT name,product,provider,data_source,provider_string,
       is_data_access_enabled,is_rpc_out_enabled,
       is_collation_compatible,uses_remote_collation,
       lazy_schema_validation
FROM sys.servers
WHERE name=N'RemoteSql';

Provider strings can contain sensitive configuration, so keep the captured output in the approved restricted diagnostic record. Verify the installed provider and its supported build separately. Server options are not the full inventory of provider-level settings. Inspect those settings through the approved SQL Server administration process and retain the current values before considering a change.

Avoid switching every provider option until the query works. Running a provider in-process or delaying schema validation changes operational behavior and needs its own justification. A metadata disagreement is not automatically a reason to expand permissions, disable encryption, or alter the provider's hosting mode.

Reduce the Query to an Explicit Projection

Start with one affected table and the smallest column list. Remove SELECT star so an added remote column cannot silently change the result contract. The examples assume a linked server named RemoteSql that connects to another SQL Server with a SalesDb database and a dbo.Orders table.

SELECT OrderID,OrderCode,Amount
FROM RemoteSql.SalesDb.dbo.Orders
WHERE OrderID=101;
SELECT OrderID,OrderCode,Amount
FROM OPENQUERY(RemoteSql,
    'SELECT OrderID,OrderCode,Amount FROM SalesDb.dbo.Orders WHERE OrderID=101');

OPENQUERY sends the enclosed statement for remote execution and can avoid a problematic distributed-query metadata path. It does not guarantee that every provider inconsistency disappears. Compare the exact same rows and projected columns, then inspect what changes in the local plan and result metadata. Keep remote filtering inside the pass-through statement where it is appropriate.

A successful pass-through query is evidence about that shape. It is not proof that every join, parameterized workload, or application result remains compatible. Include the real caller's required columns, values, and cardinality in the next test. A provider can agree on a tiny example while disagreeing on the operation that matters.

Stabilize Expression Types With a Reviewed Cast

An explicit remote CAST can make the returned type, length, precision, or scale more predictable. Choose the target from the accepted business contract and actual values. The following projection fixes a string length and decimal type at the remote query boundary.

SELECT OrderID,OrderCode,Amount
FROM OPENQUERY(RemoteSql,
    'SELECT CAST(OrderID AS bigint) AS OrderID,
            CAST(OrderCode AS nvarchar(100)) AS OrderCode,
            CAST(Amount AS decimal(18,2)) AS Amount
     FROM SalesDb.dbo.Orders
     WHERE OrderID=101');

Do not use a shorter string type merely because it avoids the error. Truncation can turn a technical workaround into a data-quality problem. Decimal conversion can round values or reject an out-of-range amount. Check the source's actual width and range, including NULLs and boundary values, before accepting the cast as the production contract.

SELECT MaximumCodeBytes,MinimumAmount,MaximumAmount
FROM OPENQUERY(RemoteSql,
    'SELECT MAX(DATALENGTH(OrderCode)) AS MaximumCodeBytes,
            MIN(Amount) AS MinimumAmount,MAX(Amount) AS MaximumAmount
     FROM SalesDb.dbo.Orders');

This aggregate can read substantial remote data, so run it in an approved diagnostic window or use an accepted representative copy. A measured maximum does not replace the declared future contract. If the column is intended to accept longer values tomorrow, the chosen projection must accommodate that requirement too.

Refresh a View When Its Stored Metadata Is Stale

A non-schema-bound view can retain metadata that needs refreshing after underlying objects change. Review the view's definition and dependencies on the instance where the view exists. For a local view wrapping the linked query, refresh that local object after establishing the intended remote projection.

EXEC sys.sp_refreshview N'dbo.RemoteOrdersView';
EXEC sys.sp_describe_first_result_set
    @tsql=N'SELECT OrderID,OrderCode,Amount FROM dbo.RemoteOrdersView;';

The named local view must already exist. If the stale view is remote, perform the reviewed refresh in that remote database under the appropriate permissions. A local refresh cannot repair a remote view's stored metadata. Recheck the result contract and dependent modules afterward rather than assuming a refresh preserves every expected consumer shape.

If the linked-server definition points at a changed destination or uses obsolete configuration, review and correct that definition separately. Recreating it requires preserving approved login mappings, provider details, options, and dependent callers. Do not drop a shared definition as the first diagnostic experiment. That change has a larger effect than refreshing one view.

Verify the Workload After Fixing Msg 7356

Re-run the minimized query, the caller's full projection, and representative boundary cases under the intended identity. Compare returned values and types. Capture the accepted statement and configuration so another operator can reproduce the outcome. I retain the original failure and the narrow change that addressed it in the diagnostic record.

Which remote schema change preceded the first failure? Check that evidence together with provider updates and deployment history. If Msg 7356 remains after the projected types are explicit, investigate the provider's supported metadata behavior and obtain the relevant diagnostic evidence. A cast is a useful compatibility boundary, not a universal repair instruction.

Prevent Msg 7356 With an Explicit Remote Contract

Document the accepted column list and types with the caller. Coordinate future remote changes with that contract and test them before deployment. Use a stable remote view or projection when it reduces accidental result-shape changes, while keeping its maintenance owner clear.

Msg 7356 becomes easier to resolve when the investigation follows one column from definition to runtime. Compare the layers, choose a supported correction, and validate values as well as successful execution. An error that disappears by shortening the data has not been resolved correctly.

Related reading on this blog: Linked Servers and What Goes Wrong With Them and Linked Server Logins: Stop Mapping Everyone to sa.

A metadata workaround is not a compatibility guarantee, it is a candidate correction that needs schema and value validation.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.