`sp_columns_ex behaves differently in containerized Windows environment`

1

We are observing inconsistent behavior of a SQL Server system stored procedure across different execution environments.

The following query executes successfully on a **standard physical Windows environment**:

```sql

EXEC sp_columns_ex

 @table_server = N'<ServerName>', 

 @table_name   = N'<TableName>';

```

However, when the same query is executed from an application running inside a **containerized / virtualized Windows environment (KubeVirt)**, the procedure does not return any result and appears to remain blocked indefinitely. No SQL error or exception is reported.

Additional details:

* Database connection is established successfully

* Other SQL queries and stored procedures execute without issue

* Same SQL Server instance and database are used in both environments

* The issue is isolated to `sp_columns_ex`

* Increasing client-side command timeout does not resolve the behavior

This suggests a possible dependency on environment-specific metadata resolution or client/driver behavior.

**Queries for clarification:**

1. Is `sp_columns_ex` deprecated or known to have limitations in containerized or virtualized Windows environments?

2. Are there any SQL Server or client configuration settings that influence its execution?

3. What is the recommended, supported approach to retrieve table column metadata in an environment-independent manner?

Any guidance or best practices would be appreciated.

2

I suspect the catalog views would be the normal approach. If using linked servers try both OPENQUERY and four part naming.

DECLARE @SchemaName sysname = 'dbo'
    ,@TableName  sysname = 'YourTableName';

SELECT C.[name] AS ColumnName
    ,T.[name] AS DataType
    ,C.max_length AS MaxLengthBytes
    ,C.[precision] AS NumericPrecision
    ,C.scale AS NumericScale
    ,C.is_nullable AS IsNullable
    ,C.column_id AS ColumnID
    ,C.collation_name AS CollationName
    ,C.is_identity AS IsIdentity
    ,C.is_computed AS IsComputed
FROM sys.columns C
    JOIN sys.types T
        ON C.user_type_id = T.user_type_id
    JOIN sys.objects O
        ON C.object_id = O.object_id
    JOIN sys.schemas S
        ON O.schema_id = S.schema_id
WHERE O.type = 'U'  -- User tables
    AND S.[name] = @SchemaName
    AND O.[name] = @TableName
ORDER BY C.column_id;
1 Like
3

Any command to check all drivers/providers are properly installed ?

4
5

The difference you’re seeing with sp_columns_ex in the container usually comes down to the SQL client libraries inside the Windows container. Containers often ship with older or minimal MDAC/ODBC components, so the procedure ends up returning fewer details because the underlying provider doesn’t expose the same metadata as a full Windows installation. Updating the SQL client stack inside the container, ODBC Driver 18/19 or the latest SQLCMD/SQL tools usually brings the behavior back in line with what you see on a normal Windows host. Once the container has the modern drivers installed, sp_columns_ex tends to return the full metadata again.