After upgrading to SQL Server 2019 CU2, I noticed some issues when trying to connect to a Cosmos DB collection via PolyBase. Specifically, I started getting the following error message:
Msg 105082, Level 16, State 1, Line 35
105082;Generic ODBC error: [Microsoft][MongoDBODBC] (110) Error from MongoDB Client: Server at <<my Cosmos account name>>.documents.azure.com:10255 reports wire version 2, but this version of libmongoc requires at least 3 (MongoDB 3.0) (Error Code: 15) Additional error <2>: ErrorMsg: [Microsoft][MongoDBODBC] (110) Error from MongoDB Client: Server at <<my Cosmos account name>> .documents.azure.com:10255 reports wire version 2, but this version of libmongoc requires at least 3 (MongoDB 3.0) (Error Code: 15), SqlState: HY000, NativeError: 110 .
This account had worked through SQL Server 2019 and I hadn’t changed anything on Cosmos DB’s side.
The Solution
After reaching out regarding the issue, I learned that the PolyBase ODBC driver for MongoDB (which SQL Server uses to connect to Cosmos DB) was updated in CU2.
A New Account?
The word I got was that, if you received the error above, you would have to upgrade your Cosmos DB account from API version 3.2 to API version 3.6. There isn’t a nice way to do this, so I created a new account.
Well, I tried that and no dice—I still got the same error. Fortunately, there is a workaround.
The Workaround: Reverting the Driver Change
The workaround is to revert back to the original MongoDB driver that PolyBase used. You can find this driver in your SQL Server installation path, which by default is %PROGRAMFILES%\MSSQL15.{Instance}\MSSQL\Binn\PolyBase\ODBC Drivers.
Inside this folder, there is a file named PolyBase ODBC Driver for MongoDb.ini. Open this file and make the following edit:
As of CU2, the driver and setup have moved to a path PolyBase ODBC Driver for MongoDb\2.3.8\. Remove the 2.3.8\ and you revert SQL Server back to its pre-upgrade version of the Mongo driver. You’ll need to restart the PolyBase services, but you do not need to restart the database engine.
Once you do that, you should be able to create external tables against a Cosmos DB account, whether that account is using version 3.2 or 3.6.
Conclusion
For now, I recommend reverting the MongoDB driver if you want to connect to Cosmos DB and experience the problem listed above. I’ll update this post as I learn more about the issue, and hopefully, everything will be sorted out.
36 Chambers - The Legendary Journeys: Execution to the max! 
I have a 3.6 CosmosDB with MongoDB API and a SQL 2019 CU4 and I cannot get past a error message that my column does not exist in the database. I know the column is there. I only have one document with _id and City defined in the explorer…
105083;The following columns in the user defined schema are incompatible with the external table schema for table ‘Cities’: user defined column: ‘City’ was not found in the external table. The detected external table schema is: ([_id] NVARCHAR(24) COLLATE Latin1_General_100_CI_AS NOT NULL).