SOLVED

ADO & VARCHAR

%3CLINGO-SUB%20id%3D%22lingo-sub-264369%22%20slang%3D%22en-US%22%3EADO%20%26amp%3B%20VARCHAR%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-264369%22%20slang%3D%22en-US%22%3E%3CP%3E%3CBR%20%2F%3EThe%20following%20has%20been%20encountered%20on%3C%2FP%3E%3CP%3EWindows%20Server%202019%20Insider%20Preview%20Build%2017744%3CBR%20%2F%3E(also%20on%20Windows%2010%20Insider%20Preview%20Build%2017763.1%2C%20though%20our%20customers%20typically%20use%20Windows%20Server%20for%20the%20affected%20product)%3C%2FP%3E%3CP%3EI%20have%20been%20trying%20for%20weeks%20to%20find%20the%20correct%20place%20to%20report%20this.%3C%2FP%3E%3CP%3E%3CBR%20%2F%3EWe%20are%20seeing%20problems%20using%20ADO%20when%20returning%20record%20sets%20that%20contain%20VARCHAR%20columns%20(adVarChar(n)%20type).%20Other%20data%20types%20seem%20to%20be%20OK.%3C%2FP%3E%3CP%3E%3CBR%20%2F%3EHere%20is%20a%20sample%20app%20(vs2017)%20that%20illustrates%20the%20problem%2C%20which%20we%20see%20on%20Windows%20Server%202019%20%26amp%3B%20Window%2010%20Oct%202018%20Preview.%20It%20runs%20fine%20on%20earlier%20systems.%3C%2FP%3E%3CP%3E%3CBR%20%2F%3E%2F%2F%20ConsoleApplication1.cpp%20%3A%20Built%20using%20VS2017%20This%20file%20contains%20the%20'main'%20function.%20Program%20execution%20begins%20and%20ends%20there.%3CBR%20%2F%3E%2F%2F%3C%2FP%3E%3CP%3E%23include%20%22pch.h%22%3CBR%20%2F%3E%23include%20%3CIOSTREAM%3E%3CBR%20%2F%3E%23import%20%22msado15.dll%22%20no_namespace%20rename(%22EOF%22%2C%20%22adoEOF%22)%20implementation_only%3CBR%20%2F%3E%23include%20%3CSTRING%3E%3CBR%20%2F%3E%23include%20%3CTCHAR.H%3E%3C%2FTCHAR.H%3E%3C%2FSTRING%3E%3C%2FIOSTREAM%3E%3C%2FP%3E%3CP%3Eint%20main()%3CBR%20%2F%3E%7B%3CBR%20%2F%3Estd%3A%3Acout%20%26lt%3B%26lt%3B%20%22Hello!%5Cn%22%3B%3C%2FP%3E%3CP%3Eif%20(FAILED(%3A%3ACoInitialize(NULL)))%3CBR%20%2F%3Ereturn%20-1%3B%3CBR%20%2F%3Etry%3CBR%20%2F%3E%7B%3CBR%20%2F%3E_RecordsetPtr%20rs%3B%3CBR%20%2F%3EHRESULT%20hr%20%3D%20rs.CreateInstance(__uuidof(Recordset))%3B%3CBR%20%2F%3Eif%20(FAILED(hr))%3CBR%20%2F%3E%7B%3CBR%20%2F%3Ethrow%20_com_error(hr)%3B%3CBR%20%2F%3E%7D%3CBR%20%2F%3Ers-%26gt%3BCursorLocation%20%3D%20adUseClient%3B%3CBR%20%2F%3E%3CBR%20%2F%3Econst%20_bstr_t%20shape%20%3D%20%22SHAPE%20APPEND%20NEW%20adVarChar(254)%20AS%20SrcDestName%22%3B%3C%2FP%3E%3CP%3E%2F*%3CBR%20%2F%3EThe%20following%20call%20works%20on%20Windows%202012R2%20but%20fails%20on%20Windows%202019%20with%3A%3CBR%20%2F%3ECode%20%3D%2080040e14%3CBR%20%2F%3ECode%20meaning%20%3D%20I%3CBR%20%2F%3ESource%20%3D%20MSDataShape%3CBR%20%2F%3EDescription%20%3D%20Length%20of%20NEW%20column%20SrcDestName%20cannot%20be%20zero.%3CBR%20%2F%3E*%2F%3C%2FP%3E%3CP%3E%2F%2F%20Note%20debug%20output%20in%20W2019%20has%20this%20error%3A%20%22Invalid%20parameter%20passed%20to%20C%20runtime%20function.%22%20-%20which%20is%20not%20emitted%20when%20running%20on%202012R2%3CBR%20%2F%3Ers-%26gt%3BOpen(shape%2C%20_T(%22Provider%3DMSDataShape%3Bdata%20provider%3DNONE%22)%2C%20adOpenForwardOnly%2C%20adLockOptimistic%2C%20adCmdText)%3B%3CBR%20%2F%3E%3CBR%20%2F%3Estd%3A%3Acout%20%26lt%3B%26lt%3B%20%22Success!%5Cn%22%3B%3CBR%20%2F%3E%7D%3C%2FP%3E%3CP%3Ecatch%20(_com_error%20%26amp%3Be)%3CBR%20%2F%3E%7B%3CBR%20%2F%3E_bstr_t%20bstrSource(e.Source())%3B%3CBR%20%2F%3E_bstr_t%20bstrDescription(e.Description())%3B%3C%2FP%3E%3CP%3E%2F%2F%20Print%20COM%20errors.%3CBR%20%2F%3Eprintf(%22Error%5Cn%22)%3B%3CBR%20%2F%3Eprintf(%22%5CtCode%20%3D%20%2508lx%5Cn%22%2C%20e.Error())%3B%3CBR%20%2F%3Eprintf(%22%5CtCode%20meaning%20%3D%20%25s%5Cn%22%2Ce.ErrorMessage())%3B%3CBR%20%2F%3Eprintf(%22%5CtSource%20%3D%20%25s%5Cn%22%2C%20(LPCSTR)bstrSource)%3B%3CBR%20%2F%3Eprintf(%22%5CtDescription%20%3D%20%25s%5Cn%22%2C%20(LPCSTR)bstrDescription)%3B%3CBR%20%2F%3E%7D%3CBR%20%2F%3E%3CBR%20%2F%3E%3A%3ACoUninitialize()%3B%3CBR%20%2F%3Estd%3A%3Acout%20%26lt%3B%26lt%3B%20%22Goodbye!%5Cn%22%3B%3CBR%20%2F%3E%7D%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-264369%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EGeneral%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-310433%22%20slang%3D%22en-US%22%3ERe%3A%20ADO%20%26amp%3B%20VARCHAR%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-310433%22%20slang%3D%22en-US%22%3E%3CP%3EThat's%20a%20good%20workaround!%20Thanks%20for%20sharing.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHowever%2C%20in%20my%20case%20I%20have%20no%20access%20to%20the%20application%20source%20code%2C%20so%20that%20I%20could%20change%20replace%20adVarChar%20with%20adLongVarChar...%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI'm%20starting%20to%20believe%20that%20Microsoft%20has%20no%20intention%20to%20fix%20this%20issue%2C%20since%20they've%20warned%20us%20about%20the%20eminent%20deprecation%20of%20the%20feature.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnyway%2C%20I'll%20keep%20on%20looking%20for%20a%20workaround%20to%20my%20specific%20scenario.%3C%2FP%3E%3CP%3EAny%20help%20would%20be%20appreciated!%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-270941%22%20slang%3D%22en-US%22%3ERe%3A%20ADO%20%26amp%3B%20VARCHAR%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-270941%22%20slang%3D%22en-US%22%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAha%20-%20found%20other%20postings%20with%20the%20same%20issue%2C%20and%20someone%20posted%20a%20workaround%20(which%20seems%20to%20be%20working%20for%20us).%20I%20think%20it%20still%20a%20bug%20and%20a%20serious%20regression%2C%20but%20at%20least%20we%20can%20move%20forward%20(we%20happen%20to%20be%20at%20a%20point%20in%20the%20product%20cycle%20where%20we%20can%20put%20in%20a%20change%20like%20this)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fstackoverflow.com%2Fquestions%2F52650021%2Fmsdatashape-error-broken-on-upgrade-to-windows-10-feature-update-1809%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fstackoverflow.com%2Fquestions%2F52650021%2Fmsdatashape-error-broken-on-upgrade-to-windows-10-feature-update-1809%3C%2FA%3E%3C%2FP%3E%3CP%3E%3CBR%20%2F%3E*%20workaround%20for%20this%20issue%20...%20Replacing%20adVarChar(%23%23)%20with%20adLongVarChar%20does%20the%20job%20for%20me%20...%3C%2FP%3E%3CP%3EThis%20workaround%20is%20not%20applicable%20to%20queries%20like%3C%2FP%3E%3CP%3ESHAPE%20APPEND%20NEW%20adLongVarChar%20As%20INVNO%2C%20NEW%20adLongVarChar%20As%20iCP%2C%3CBR%20%2F%3E((SHAPE%20APPEND%20NEW%20aadLongVarChar%20As%20INVNO%2CNEW%20adLongVarCharAs%20iCP%2CNEW%20adLongVarChar%20As%20F1%2CNEW%20adLongVarChar%20As%20F2%2CNEW%20adLongVarChar%20As%20F3)%3CBR%20%2F%3EAS%20Trans%20RELATE%20INVNO%20TO%20INVNO%2CiCP%20TO%20iCP)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E*%20someone%20else%20suggested%20using%20adLongVarWChar%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E*%20there%20was%20also%20mention%20of%20a%20future%20deprecation%20of%20the%20Data%20Shaping%20Service%20for%20OLE%20DB%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsql%2Fado%2Fguide%2Fappendixes%2Fmicrosoft-data-shaping-service-for-ole-db-ado-service-provider%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsql%2Fado%2Fguide%2Fappendixes%2Fmicrosoft-data-shaping-service-for-ole-db-ado-service-provider%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-268302%22%20slang%3D%22en-US%22%3ERe%3A%20ADO%20%26amp%3B%20VARCHAR%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-268302%22%20slang%3D%22en-US%22%3E%3CP%3EThanks%20for%20creating%20another%20post.%26nbsp%3B%20This%20is%20a%20serious%20issue.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHopefully%20by%20generating%20enough%20traffic%20on%20this%20forum%20we%20can%20gain%20someone's%20attention!!%26nbsp%3B%20Or%20at%20least%20hear%20of%20others%20having%20this%20problem.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-267399%22%20slang%3D%22en-US%22%3ERe%3A%20ADO%20%26amp%3B%20VARCHAR%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-267399%22%20slang%3D%22en-US%22%3E%3CDIV%3EI%20also%20do%20not%20know%20how%20to%20do%20that.%20But%20I%20created%20another%20post%20on%3A%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CA%20href%3D%22https%3A%2F%2Fsocial.msdn.microsoft.com%2FForums%2Fen-US%2F2705acfa-46c7-4d30-b10b-26b043591c6f%2Fplease-read-problem-with-ado-vachar-in-windows-10-update-1809-and-server-2019%3Fforum%3Dadodotnetdataset%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fsocial.msdn.microsoft.com%2FForums%2Fen-US%2F2705acfa-46c7-4d30-b10b-26b043591c6f%2Fplease-read-problem-with-ado-vachar-in-windows-10-update-1809-and-server-2019%3Fforum%3Dadodotnetdataset%3C%2FA%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3ELet's%20pray%20that%20they%20resolve%20quickly%2C%20if%20I%20have%20any%20news%2C%20I'll%20let%20you%20know.%3C%2FDIV%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-266969%22%20slang%3D%22en-US%22%3ERe%3A%20ADO%20%26amp%3B%20VARCHAR%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-266969%22%20slang%3D%22en-US%22%3E%3CP%3EThank%20you!%26nbsp%3B%20It's%20good%20to%20know%20that%20we%20are%20not%20the%20only%20ones%20having%20this%20problem.%26nbsp%3B%20Now%20how%20do%20we%20get%20Microsoft's%20attention%3F%26nbsp%3B%20We%20were%20hoping%20that%20taking%20the%20effort%20to%20create%20the%20simple%20repro%20might%20speed%20up%20a%20solution%2C%20but%20so%20far%20I%20have%20not%20seen%20any%20response.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3BWith%20Windows%2010%2C%20the%20update%20to%20the%20semi-annual%20update%20happens%20automatically%2C%20so%20dropping%20back%20to%201803%20is%20not%20really%20a%20solution%20for%20most%20folks.%26nbsp%3B%20%26nbsp%3BFortunately%2C%20our%20application%20is%20run%20primarily%20on%20Windows%20Server%20(though%20a%20few%20prospects%20may%20run%20it%20on%20a%20desktop%20OS%20for%20a%20proof-of-concept%20trial)%2C%20and%20for%20the%20moment%20we%20can%20tell%20our%20customers%20to%20avoid%20Windows%20Server%202019%2C%20but%20that%20is%20not%20a%20long-term%20solution.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-266966%22%20slang%3D%22en-US%22%3ERe%3A%20ADO%20%26amp%3B%20VARCHAR%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-266966%22%20slang%3D%22en-US%22%3EAny%20news%3F%3CBR%20%2F%3EI%20am%20also%20having%20problems%20when%20I%20use%20Ole%20DB%20Provider%3A%20MSDataShape%2C%20when%20the%20SHAPE%20APPED%20command%20has%20a%20column%20declared%20as%20NEW%20adVarchar%20(50)%20ColumnName.%20When%20opening%20the%20dataset%2C%20you%20get%20an%20error%20saying%20that%20the%20column%20can%20not%20have%20zero%20length.%20This%20started%20after%20the%201809%20update%20of%20windows%2010.%20To%20resolve%20I%20removed%20this%20update%2C%20returning%20to%201803.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-266943%22%20slang%3D%22en-US%22%3ERe%3A%20ADO%20%26amp%3B%20VARCHAR%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-266943%22%20slang%3D%22en-US%22%3E%3CP%3EAny%20updates%20on%20this%3F%26nbsp%3B%20I%20can't%20believe%20we%20are%20the%20only%20ones%20having%20this%20problem.%26nbsp%3B%20Is%20Microsoft%20monitoring%20this%20forum%2C%20and%20if%20not%2C%20where%20is%20the%20correct%20place%20to%20report%20problems%20with%20Windows%20Server%202019%20Preview%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
StarQuest Ventures
Occasional Contributor


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";
}

7 Replies

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?

Any news?
I am also having problems when I use Ole DB Provider: MSDataShape, when the SHAPE APPED command has a column declared as NEW adVarchar (50) ColumnName. When opening the dataset, you get an error saying that the column can not have zero length. This started after the 1809 update of windows 10. To resolve I removed this update, returning to 1803.

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.

I also do not know how to do that. But I created another post on:
 
 
Let's pray that they resolve quickly, if I have any news, I'll let you know.

 

 

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.

 

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)

 

https://stackoverflow.com/questions/52650021/msdatashape-error-broken-on-upgrade-to-windows-10-featu...


* 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

https://docs.microsoft.com/en-us/sql/ado/guide/appendixes/microsoft-data-shaping-service-for-ole-db-...

 

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!

 

Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
50 Replies
Extentions Synchronization
Deleted in Discussions on
3 Replies
Stable version of Edge insider browser
HotCakeX in Discussions on
35 Replies
How to Prevent Teams from Auto-Launch
chenrylee in Microsoft Teams on
32 Replies
Security Community Webinars
Valon_Kolica in Security, Privacy & Compliance on
15 Replies
Discussion - Updating our interface with Fluent touches
Elliot Kirk in Discussions on
102 Replies