Sometimes I swear we're living in the digital stone ages.
It turns out - unless someone can point me to something I'm missing, that ODBC 32 bit cannot handle a unicode pathname which contains non-default-locale characters in it.
It does handle a pathname that has non-English chars if the local system is set to be in that same default locale (e.g. Kanji chars when the locale is Japan).
But it fails utterly with "Not a valid filename" from both our code, and from the ODBC 32 bit control panel, for a pathname which contains non-default-locale characters in it.
That same file does load properly using the 64 bit ODBC control panel, and it loads just fine running MS Access 2013 on the pathname directly.
"C:\Users\steve\Desktop\タシロ\Cimex2.mdb"
From the ODBC 32 control panel, this results in:
ODBC Microsoft Access Driver Login Failed
Not a valid file name.
Or from our code calling into ODBC directly as a 32-bit process I get:
Not a valid file name.
Driver's SQLSetConnectAttr failed
Which is due to an error retcode in a call to:
::SQLDriverConnect(hDBC, hWnd, pszConnectInput, SQL_NTS, szConnectOutput,
_countof(szConnectOutput), &nResult, wConnectOption));
UPDATE: I was asked to provide the runtime state at the point of this call:
The connection was created using:
L"DSN=Cimex Database|UserCommitSync=Yes|DBQ=C:\\Users\\steve\\Desktop\\タシロ\\Cimex2.mdb"
And theSQLDriverConnect is being passed:
L"DSN=Cimex Database;"
And I have verified that the ODBC connection that is created is indeed valid (other than it also fails due to invalid filename from the ODBC cpl) - but if I change the pathname to use a non Kanji path, then this all works as it has for ages). Similarly, I have manually created an ODBC connection directly and from scratch in the ODBC 32 cpl - as well as in the ODBC 64 cp - and for identical settings - only the 64 bit version works - same .mdb & path - but the 32 bit fails. And lest you think "it must be the .mdb" - if I put the .mdb in a non-Kanji path, it works just fine from our software and from the ODBC 32 cpl.
So, it appears to me, and I cannot find a loop-hole, that 32bit ODBC Access driver simply cannot handle Unicode path names that have non-default-locale characters in them. >:(
Note: I thought maybe SQL_NTS should be SQL_NTSL (I cannot for the life of me find a !##$!##$ definition of those two different arguments), but rewiring the calls to end up with SQL_NTSL doesn't help - same results
Anyone want to confirm or deny that this is a major freakin' bug still lurking in MS's 32bit Access ODBC implementation (and since it's all Jet engine based - then presumably this applies to all DBs which go through the 32 bit Jet engine)?
Related
I noticed that the folder c:\windows has two different creation dates, depending on whether you view the file system from a 32 or 64 application.
Too test it, use the open-file-dialog of any 32/64 application and check the folder properties.
How can I get the value that 32 bit application would get, from my 64 bit application?
I already tried Wow64EnableWow64FsRedirection in all combinations, but that seems to have no effect for this folder.
Update: In a 32-bit application I can get the "64-bit date", by using CreateFile and GetFileTime. And the "32-bit date" by using FindFirstFile. In a 64-bit application, both methods give me the "64-bit date".
Update:
Screenshots from properties dialog of c:\windows. Both images from the same PC.
Update 2:
I found a source describing NTFS timestamps, and there are indeed 2 creation dates. I suspect that they are usually the same and that Windows 32 and 64 bit query different parts of them without anybody noticing. Deliberately accessing them seems difficult. I didn't find any API functions, just big libraries parsing the file systems table on their own. But that is getting too big for me, just for querying the timestamp, so I'll give up here.
I seem to be able to access the functions in C:\WINDOWS\system32\opengl32.dll (and likewise C:\WINDOWS\system32\glu32.dll) from either a 32-bit or a 64-bit application (for what it's worth, I'm doing this from separate 32-bit and 64-bit Python 2.7 interpreters, via the ctypes module).
With glut32.dll, things are different. It only happens to be on my Path as part of a 32-bit installation of GraphViz. From 32-bit Python, I can link dynamically to it, but from 64-bit Python I get [Error 193] %1 is not a valid Win32 application.
Now, this error does not surprise me, because I had always thought DLLs were obliged to commit to one architecture or another on Windows (in particular, this recent question and its answers seem to say so). What surprises me is the lack of an error in the first case... How does opengl32.dll do it, and how can I replicate this behaviour when building my own DLLs?
On 64 bit system only 64 bit processes use c:\Windows\System32\opengl32.dll. For 32 bit processes system redirects c:\Windows\System32\opengl32.dll to c:\Windows\SysWOW64\opengl32.dll.
File System Redirector
In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64. Access to %windir%\lastgood\system32 is redirected to %windir%\lastgood\SysWOW64. Access to %windir%\regedit.exe is redirected to %windir%\SysWOW64\regedit.exe.
The 32-bit version of our app is unable to send email using MAPISendMail with 64-bit Outlook installed. It returns an error 0x80004005, about which I can find little information beyond the fact that it seems to be a MAPI initialization error.
According to this MSDN document, MAPISendMail is the one exception to the rule that 32-bit apps can't use 64-bit MAPI. And yet it doesn't work (at least with XP and Vista--we haven't tested Win7/8 yet).
Can anyone shed any light on this?
TIA
There are no exceptions: a 32 bit process cannot load a 64 bit dll.
When you have the 64 bit version of Outlook, the 64 bit version of mapi32.dll contains the actual implementation. The 32 bit version of mapi32.dll is a stub that does nothing but return an error.
That's not completely true #DmitryStreblechenko, - at least not for the MAPISendMail function. For that, and only for that, it is possible to build a "Outlook64 Bridge". This will then redirect 32bit MAPISendMail calls to 64bit Outlook. That bridge may look like:
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Outlook64Bridge]
#="Outlook64Bridge"
"DLLPathEx"="c:\\Windows\\winsxs\\x86_microsof t-windows-mapi_31bf3856ad364e35_6.1.7600.16385_none_ab239772 7b134496\\MAPI32.DLL"
"DLLPath"="c:\\Windows\\winsxs\\x86_microsoft-windows-mapi_31bf3856ad364e35_6.1.7600.16385_none_ab239772 7b134496\\MAPI32.DLL"
IMPORTANT, - you have first check to correct path of your 32bit mapi32.dll!
After adding these lines to the reg you have to set the Outlook64Bridge as your default mail client by:
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail]
#="Outlook64Bridge"
It is confirmed to work for simple 32bit applications which use really only the MAPISendMail function.
More information can be found here
Years ago I'had the same problem. I tried and tried again, but no way ... Microsoft blocked some interactions between 32 bit and 64 bit application: you can't even use 64 bit OCX/OLE in a 32 bit application.
The Outlook Bridge solution above (#VMAtm), worked in the beginning, then Microsoft fixed it, and it stoppend working.
In the end I realized a 64 bit application, my bridge application, to connect main 32 bit application with 64 bit outlook:
Main 32 bit application is running ...
Main 32 bit call bridge 64 bit application; mail data (from, to, title, body ...) are stored in a xml-file. The xml file is passed via command-line.
64 bridge applicatio starts, and call MAPI functions.
64 bit outlook does the rest.
This solutions works fine, and I'm quite sure I don't have to struggle with MAPI libraries.
I have set up the QODBC driver and was able to connect to my QB file and run queries in the VB Demo 32.
I am looking at one of the Sample Files, found here - http://support.flexquarters.com/esupport/index.php?/Default/Knowledgebase/Article/View/506/57/examples-of-how-to-use-qodbc-via-visual-basic
I did what this article said - copied all of the text into a text file, saved it as "Customer.vbs". I created a Customer named "Kim Garland", closed the dialogue box, double clicked on the file. The msgbox never displayed, and this error message came up - "[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application; Code: 80004005; Source: Microsoft OLE DB Provider for ODBC Drivers"
Any idea what is going on here? After looking through the knowledge base, I thought it might have something to do with 64-bit vs 32-bit... but that didn't seem to get me anywhere. I do have Visual Studio installed, but don't quite know enough about VB6 apps to know what I'm doing.
EDIT
By the way, the line that is giving the error is:
oConnection.Open "DSN=Ben Test 2;OLE DB Services=-2"
I originally was using the same exact line that was in the article that I linked to, but that was not working either. I used the c:\windows\syswow64\odbcad32.exe to create a 32-bit DSN called "Ben Test 2". It didn't seem to change anything.
Please take a look at the Microsoft's website where they talk about it.
It is not VB issue, it is 32/64bit issue as you suspect.
http://social.msdn.microsoft.com/Forums/en/sqlgetstarted/thread/702f0d9b-6cb9-49cf-9953-80d059711e60
Since you are using 64-bit system, your VBS will be execute as 64-bit (by default).
QODBC is 32-bit driver, and can work with 32-bit applications. A 64-bit applications cannot talk to a 32 bit Driver and same is with 64bit application to 32 bit Driver.
For 64-bit applications use QRemote (which is a 64-bit Driver driver).
Solution 1
You can try to use QRemote to bridge QODBC and your application. Here is an article about how to use QRemote:
http://www.qodbc.com/qremoteconnect.htm
Solution 2
and there is another solution for you issue. Please call your VBS as 32 bit. Please follow the steps below:
1) Click Windows Start
2) Click Run, in the window, type "%windir%\SysWoW64\cmd.exe"
3) Click OK, then type "cscript vbscriptfile.vbs" in the cmd window
This will make your VBS run in 32-bit mode even thou you are in 64-bit machine
-Regards
Rajendra Dewani
We have an application that sets up an IP address on a bit of embedded hardware. Part the the process is to setup and ARP mapping to map the new (but not yet assigned) address to the MAC address of the device.
Under XP this works perfectly and this code hasn't been touched since 2003. Under Win 7 64 bit (maybe 32 bit as well I haven't tried it) the call to CreateIpNetEntry returns a 0 success code but no entry is created in the ARP table. I'm running the exe as administrator so permissions shouldn't be the problem. I even tried adding a manifest file to force the requested execution level to requireAdministrator.
If it returned an error I might have something to go on but it returns a success code and doesn't do anything!