Azure Cosmos DB (NoSQL / Core SQL API): Container created with newer SDK (V2 / large or hierarchical partition key) cannot be read by older SDK — HTTP 400 "collection cannot be accessed with this SDK version"

Question

Azure Cosmos DB (NoSQL / Core SQL API): Container created with newer SDK (V2 / large or hierarchical partition key) cannot be read by older SDK — HTTP 400 "collection cannot be accessed with this SDK version"

Weezelboy 1

We are querying Azure Cosmos DB from SQL Server via a linked server (MSDASQL OLE DB provider over an ODBC driver for the Cosmos DB / DocumentDB SQL API). Authentication now succeeds, but the connection fails during container access with the following error:

Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "COSMOS". [Microsoft][DocumentDB] (400) HTTP 400 Bad Request: {"code":"BadRequest","message":"{"Errors":["The collection cannot be accessed with this SDK version as it was created with newer SDK version."]}"}

The driver reports its bundled SDK as cosmos-netstandard-sdk/3.18.0.

What we understand so far: This appears to be a partition-key-version / capability mismatch — one or more of our containers were created with a newer feature (we believe PartitionKeyDefinitionVersion = V2 / large partition keys, or possibly hierarchical/sub-partitioned partition keys) that the older bundled SDK cannot read. The linked server enumerates all containers on connect, so a single incompatible container appears to fail the whole connection.

Questions for support:

Can you confirm that this specific error is caused by the container's partition key version (V2 / large partition keys) or hierarchical partition keys, versus some other newer feature? Is there a way for us to query which of our containers are affected (e.g., how to read the PartitionKeyDefinitionVersion per container)?
What is the minimum Cosmos DB SDK version required to read containers created with (a) large partition keys / PK version 2, and (b) hierarchical partition keys? We want to confirm what a client must bundle to be compatible.
Is there a Microsoft-supported way to access Cosmos DB from SQL Server (linked server, OLE DB, ODBC, or otherwise) that supports these newer partition-key features? If ODBC/linked-server access is not supported for such containers, what is the recommended integration pattern (e.g., Synapse Link analytical store, Microsoft Fabric mirroring, or an application tier using the current SDK)?
If we must remain on the older access path, is recreating the container with PartitionKeyDefinitionVersion = V1 the correct remedy, and are there any limitations (max partition key size, feature loss) we should be aware of?

Environment details:

API: NoSQL / Core (SQL)
Client: SQL Server 14.0.3485.1 linked server → MSDASQL → ODBC driver reporting cosmos-netstandard-sdk/3.18.0
We are querying Azure Cosmos DB from SQL Server via a linked server (MSDASQL OLE DB provider over an ODBC driver for the Cosmos DB / DocumentDB SQL API). Authentication now succeeds, but the connection fails during container access with the following error:

Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "COSMOS".
[Microsoft][DocumentDB] (400) HTTP 400 Bad Request: {"code":"BadRequest","message":"{"Errors":["The collection cannot be accessed with this SDK version as it was created with newer SDK version."]}"}

Peram Venkateswara Reddy 5 Reputation points Microsoft External Staff Moderator

2026-08-05T11:04:10.93+00:00
Hi @Weezelboy , In addition to @Allan Solomon Mejia response I would like to add below points.

Based on the error message:

Collection`` ``cannot`` ``be`` ``accessed`` ``with`` ``this`` ``SDK`` ``version.`` ``Please`` ``use`` ``a`` ``newer`` ``SDK`` ``version.

this appears to be a client compatibility issue rather than an authentication or SQL Server connectivity issue.

Since the ODBC provider reports cosmos-netstandard-sdk/3.18.0, one possibility is that the Linked Server/ODBC access path does not fully support one or more container capabilities enabled on the target container. Examples could include:

Large Partition Keys (PartitionKeyDefinitionVersion`` ``=`` ``V2)

Hierarchical Partition Keys (MultiHash)

Other container metadata or capabilities introduced after the provider was developed

In such scenarios, authentication may succeed, but container discovery or metadata retrieval can fail with an HTTP 400 response similar to the one reported.

To help determine whether this is the root cause, could you confirm:

Whether the affected container uses PartitionKeyDefinitionVersion = V2 (Large Partition Keys).

Whether the container uses Hierarchical Partition Keys (MultiHash).

Whether the issue occurs only with newer containers, while older containers created with traditional partition key definitions continue to work.

Whether all containers fail through the Linked Server, or only specific containers.

If only containers using newer partition key configurations are affected, that would strongly suggest a compatibility limitation in the ODBC/OLE DB access path rather than an issue with SQL Server itself.

If compatibility is confirmed, potential options may include:

Upgrading to a newer ODBC/OLE DB provider, if one is available and supports the required Cosmos DB features.

Accessing Cosmos DB through a supported SDK-based application layer.

Evaluating other integration approaches such as Azure Data Factory, Azure Synapse Link, or Microsoft Fabric, depending on the workload requirements.

At this point, it would be helpful if a member of the Azure Cosmos DB product team could clarify whether SQL Server Linked Server/ODBC integrations are expected to support containers created with Large Partition Keys or Hierarchical Partition Keys, and whether any compatibility guidance is available for these scenarios.

If this answer helped, please consider Accepting the Answer so it can assist other community members facing a similar issue.

Kind Regards,
Microsoft Support Team.

1 answer

Your answer

Answer 1

Hello @Weezelboy

Since your ODBC provider reports cosmos-netstandard-sdk/3.18.0, it is possible that the driver embeds an older Azure Cosmos DB .NET SDK that does not understand newer container metadata introduced with features such as:

Large Partition Keys (PartitionKeyDefinitionVersion = V2)
Hierarchical Partition Keys (MultiHash)
Other newer container capabilities

If the linked server relies on that embedded SDK, authentication may succeed, but container discovery or metadata retrieval can fail with the HTTP 400 error you're seeing.

To help confirm the root cause, I would recommend verifying the following:

Whether the affected container uses PartitionKeyDefinitionVersion = V2.
Whether it uses Hierarchical Partition Keys (MultiHash).
Whether the problem occurs only with newer containers while older containers created with traditional V1 partition keys continue to work.

If those conditions are true, this would strongly indicate an SDK compatibility limitation rather than a SQL Server or authentication issue.

At that point, the available options are generally:
Upgrade to an ODBC/OLE DB provider that bundles a newer Cosmos DB SDK (if available).
Use another supported integration method (such as Azure Synapse Link, Microsoft Fabric, Azure Data Factory, or a custom application using the latest Cosmos DB SDK).

Recreate the container with a V1 partition key only if legacy Linked Server compatibility is an absolute requirement.

Hopefully, someone from the Azure Cosmos DB product team can confirm whether the SQL Server Linked Server/ODBC path currently supports containers created with Large Partition Keys or Hierarchical Partition Keys, and whether there is an official compatibility matrix or roadmap for these newer features. That information would be valuable for anyone integrating Cosmos DB through legacy ODBC/OLE DB providers.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.