Sep 28 2018 12:20 PM
The following has been encountered on
Windows Server 2019 Insider Preview Build 17744
(also on Windows 10 Insider Preview Build 17763.1, though our customers typically use Windows Server for the affected product)
I have been trying for weeks to find the correct place to report this.
We are seeing problems using ADO when returning record sets that contain VARCHAR columns (adVarChar(n) type). Other data types seem to be OK.
Here is a sample app (vs2017) that illustrates the problem, which we see on Windows Server 2019 & Window 10 Oct 2018 Preview. It runs fine on earlier systems.
// ConsoleApplication1.cpp : Built using VS2017 This file contains the 'main' function. Program execution begins and ends there.
//
#include "pch.h"
#include <iostream>
#import "msado15.dll" no_namespace rename("EOF", "adoEOF") implementation_only
#include <string>
#include <tchar.h>
int main()
{
std::cout << "Hello!\n";
if (FAILED(::CoInitialize(NULL)))
return -1;
try
{
_RecordsetPtr rs;
HRESULT hr = rs.CreateInstance(__uuidof(Recordset));
if (FAILED(hr))
{
throw _com_error(hr);
}
rs->CursorLocation = adUseClient;
const _bstr_t shape = "SHAPE APPEND NEW adVarChar(254) AS SrcDestName";
/*
The following call works on Windows 2012R2 but fails on Windows 2019 with:
Code = 80040e14
Code meaning = I
Source = MSDataShape
Description = Length of NEW column SrcDestName cannot be zero.
*/
// Note debug output in W2019 has this error: "Invalid parameter passed to C runtime function." - which is not emitted when running on 2012R2
rs->Open(shape, _T("Provider=MSDataShape;data provider=NONE"), adOpenForwardOnly, adLockOptimistic, adCmdText);
std::cout << "Success!\n";
}
catch (_com_error &e)
{
_bstr_t bstrSource(e.Source());
_bstr_t bstrDescription(e.Description());
// Print COM errors.
printf("Error\n");
printf("\tCode = %08lx\n", e.Error());
printf("\tCode meaning = %s\n",e.ErrorMessage());
printf("\tSource = %s\n", (LPCSTR)bstrSource);
printf("\tDescription = %s\n", (LPCSTR)bstrDescription);
}
::CoUninitialize();
std::cout << "Goodbye!\n";
}
Oct 04 2018 09:12 AM
Any updates on this? I can't believe we are the only ones having this problem. Is Microsoft monitoring this forum, and if not, where is the correct place to report problems with Windows Server 2019 Preview?
Oct 04 2018 09:52 AM
Oct 04 2018 09:59 AM
Thank you! It's good to know that we are not the only ones having this problem. Now how do we get Microsoft's attention? We were hoping that taking the effort to create the simple repro might speed up a solution, but so far I have not seen any response.
With Windows 10, the update to the semi-annual update happens automatically, so dropping back to 1803 is not really a solution for most folks. Fortunately, our application is run primarily on Windows Server (though a few prospects may run it on a desktop OS for a proof-of-concept trial), and for the moment we can tell our customers to avoid Windows Server 2019, but that is not a long-term solution.
Oct 05 2018 05:43 AM
Oct 08 2018 08:45 AM
Thanks for creating another post. This is a serious issue.
Hopefully by generating enough traffic on this forum we can gain someone's attention!! Or at least hear of others having this problem.
Oct 12 2018 09:15 PM
Solution
Aha - found other postings with the same issue, and someone posted a workaround (which seems to be working for us). I think it still a bug and a serious regression, but at least we can move forward (we happen to be at a point in the product cycle where we can put in a change like this)
* workaround for this issue ... Replacing adVarChar(##) with adLongVarChar does the job for me ...
This workaround is not applicable to queries like
SHAPE APPEND NEW adLongVarChar As INVNO, NEW adLongVarChar As iCP,
((SHAPE APPEND NEW aadLongVarChar As INVNO,NEW adLongVarCharAs iCP,NEW adLongVarChar As F1,NEW adLongVarChar As F2,NEW adLongVarChar As F3)
AS Trans RELATE INVNO TO INVNO,iCP TO iCP)
* someone else suggested using adLongVarWChar
* there was also mention of a future deprecation of the Data Shaping Service for OLE DB
Jan 08 2019 11:09 AM
That's a good workaround! Thanks for sharing.
However, in my case I have no access to the application source code, so that I could change replace adVarChar with adLongVarChar...
I'm starting to believe that Microsoft has no intention to fix this issue, since they've warned us about the eminent deprecation of the feature.
Anyway, I'll keep on looking for a workaround to my specific scenario.
Any help would be appreciated!
Oct 12 2018 09:15 PM
Solution
Aha - found other postings with the same issue, and someone posted a workaround (which seems to be working for us). I think it still a bug and a serious regression, but at least we can move forward (we happen to be at a point in the product cycle where we can put in a change like this)
* workaround for this issue ... Replacing adVarChar(##) with adLongVarChar does the job for me ...
This workaround is not applicable to queries like
SHAPE APPEND NEW adLongVarChar As INVNO, NEW adLongVarChar As iCP,
((SHAPE APPEND NEW aadLongVarChar As INVNO,NEW adLongVarCharAs iCP,NEW adLongVarChar As F1,NEW adLongVarChar As F2,NEW adLongVarChar As F3)
AS Trans RELATE INVNO TO INVNO,iCP TO iCP)
* someone else suggested using adLongVarWChar
* there was also mention of a future deprecation of the Data Shaping Service for OLE DB