{"id":1086,"date":"2009-10-30T10:56:38","date_gmt":"2009-10-30T08:56:38","guid":{"rendered":"https:\/\/alax.info\/blog\/?p=1086"},"modified":"2011-07-26T11:28:09","modified_gmt":"2011-07-26T09:28:09","slug":"microsoft-jet-oledb-4-0-progid-is-not-available-in-windows-7","status":"publish","type":"post","link":"https:\/\/alax.info\/blog\/1086","title":{"rendered":"Microsoft.Jet.OLEDB.4.0 ProgID is not available (Windows 7 but probably not only)"},"content":{"rendered":"

It was a sort of ridiculous problem: an attempt to instantiate a Microsoft.Jet.OLEDB.4.0 object failed with error. Still some applications are still running without problems connecting to Jet databases, how comes?<\/p>\n

There has been a number of posts on Internet<\/a>, but none of the top ones appeared to be relevant.<\/p>\n

The problem is reproduced extremely simple:<\/p>\n

int<\/span> _tmain(<\/span>int<\/span> argc,<\/span> _TCHAR*<\/span> argv[<\/span>]<\/span>)<\/span>\r\n{<\/span>\r\n    ATLVERIFY(<\/span>SUCCEEDED(<\/span>CoInitialize(<\/span>NULL<\/span>)<\/span>)<\/span>)<\/span>;<\/span>\r\n    {<\/span>\r\n        \/\/CoLoadLibrary(L\"C:\\\\Program Files (x86)\\\\Common Files\\\\System\\\\Ole DB\\\\oledb32.dll\", TRUE);<\/span>\r\n        CComPtr<<\/span>IDBInitialize><\/span> pDbInitialize;<\/span>\r\n        const<\/span> HRESULT nResult =<\/span> pDbInitialize.<\/span>CoCreateInstance(<\/span>L\"<\/span>Microsoft.Jet.OLEDB.4.0<\/span>\"<\/span>,<\/span> NULL<\/span>,<\/span> CLSCTX_INPROC_SERVER)<\/span>;<\/span>\r\n        _tprintf(<\/span>_T(<\/span>\"<\/span>nResult 0x<\/span>%08x<\/span>\\n<\/span>\"<\/span>)<\/span>,<\/span> nResult)<\/span>;<\/span>\r\n    }<\/span>\r\n    CoUninitialize(<\/span>)<\/span>;<\/span>\r\n    return<\/span> 0<\/span>;<\/span>\r\n}<\/span><\/pre>\n
Oops, the code gives error REGDB_E_CLASSNOTREG 0x80040154 “Class not registered”. It looked like system was unable to locate one of the internally used DLLs – oledb32.dll, and if we help by uncommenting the line commented in the code snippet above, the error changes to ERROR_MOD_NOT_FOUND 0x8007007e “The specified module could not be found”.<\/p>\n
The problem appears to be that one of the system components, which is involved, “Microsoft OLE DB Data Conversion Library” is registered with the system using a REG_EXPAND_SZ<\/a> value, to be located using path “%CommonProgramFiles(x86)%\\System\\Ole DB\\oledb32.dll”. It is obvious that CommonProgramFiles(x86)<\/strong> is placeholder to be expanded, but does the expansion succeed?<\/p>\n
<\/p>\n
On my system there was no such environment string, so expansion failed. There however was CommonProgramFiles<\/strong>, and it pointed to correct location. So, this hot fix makes it work right:<\/p>\n
BOOL<\/span> UpdateEnvironmentVariables(<\/span>)<\/span>\r\n{<\/span>\r\n    CString<\/span> sCommonProgramFilesX86;<\/span>\r\n    sCommonProgramFilesX86.<\/span>GetEnvironmentVariable<\/span>(<\/span>_T(<\/span>\"<\/span>CommonProgramFiles(x86)<\/span>\"<\/span>)<\/span>)<\/span>;<\/span>\r\n    if<\/span>(<\/span>sCommonProgramFilesX86.<\/span>IsEmpty(<\/span>)<\/span>)<\/span>\r\n    {<\/span>\r\n        CString<\/span> sCommonProgramFiles;<\/span>\r\n        sCommonProgramFiles.<\/span>GetEnvironmentVariable<\/span>(<\/span>_T(<\/span>\"<\/span>CommonProgramFiles<\/span>\"<\/span>)<\/span>)<\/span>;<\/span>\r\n        if<\/span>(<\/span>!<\/span>sCommonProgramFiles.<\/span>IsEmpty(<\/span>)<\/span>)<\/span>\r\n        {<\/span>\r\n            ATLVERIFY(<\/span>SetEnvironmentVariable<\/span>(<\/span>_T(<\/span>\"<\/span>CommonProgramFiles(x86)<\/span>\"<\/span>)<\/span>,<\/span> sCommonProgramFiles)<\/span>)<\/span>;<\/span>\r\n            return<\/span> TRUE;<\/span>\r\n        }<\/span>\r\n    }<\/span>\r\n    return<\/span> FALSE;<\/span>\r\n}<\/span>\r\n\r\nint<\/span> _tmain(<\/span>int<\/span> argc,<\/span> _TCHAR*<\/span> argv[<\/span>]<\/span>)<\/span>\r\n{<\/span>\r\n    ATLVERIFY(<\/span>SUCCEEDED(<\/span>CoInitialize(<\/span>NULL<\/span>)<\/span>)<\/span>)<\/span>;<\/span>\r\n    {<\/span>\r\n        UpdateEnvironmentVariables(<\/span>)<\/span>;<\/span>\r\n        CComPtr<<\/span>IDBInitialize><\/span> pDbInitialize;<\/span>\r\n        const<\/span> HRESULT nResult =<\/span> pDbInitialize.<\/span>CoCreateInstance(<\/span>L\"<\/span>Microsoft.Jet.OLEDB.4.0<\/span>\"<\/span>,<\/span> NULL<\/span>,<\/span> CLSCTX_INPROC_SERVER)<\/span>;<\/span>\r\n        _tprintf(<\/span>_T(<\/span>\"<\/span>nResult 0x<\/span>%08x<\/span>\\n<\/span>\"<\/span>)<\/span>,<\/span> nResult)<\/span>;<\/span>\r\n    }<\/span>\r\n    CoUninitialize(<\/span>)<\/span>;<\/span>\r\n    return<\/span> 0<\/span>;<\/span>\r\n} <\/span><\/pre>\n
I am under impression that the problem is not specific to Windows 7. I remember similar symptoms on Windows XP system, but they were not critical and not investigated to solution. It rather seems that OLE DB component is registering itself using a reference to environment variable which is not present on a number of systems.<\/p>\n
\n
Error code 80040154. Class not registered<\/em><\/a><\/h3>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
It was a sort of ridiculous problem: an attempt to instantiate a Microsoft.Jet.OLEDB.4.0 object failed with error. Still some applications are still running without problems connecting to Jet databases, how comes? There has been a number of posts on Internet, but none of the top ones appeared to be relevant. The problem is reproduced extremely… <\/p>\n
Read the full article<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[63,95,280,59,279,281,123,278],"class_list":["post-1086","post","type-post","status-publish","format-standard","hentry","category-technology","tag-bug","tag-com","tag-environment","tag-microsoft","tag-ole","tag-oledb","tag-registry","tag-win7"],"_links":{"self":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/posts\/1086","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/comments?post=1086"}],"version-history":[{"count":0,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/posts\/1086\/revisions"}],"wp:attachment":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/media?parent=1086"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/categories?post=1086"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/tags?post=1086"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}