This bounty has ended. Answers to this question are eligible for a +50 reputation bounty. Bounty grace period ends in 16 hours.
sandman wants to draw more attention to this question:
I would like to fix the DBX error being experienced.
I am using Delphi Berlin 10.1 to compile an app for Windows 32 bit. When clients use oracle 32 bit instant client on Windows 64 bit, they get this error:
"Could not connect to (DBX Error: driver could not be
properly initialized. Client library may be missing, not installed
properly, of the wrong version, or the driver may be missing from the
system path.)"
A way that I use to fix the problem works for some users:
C:\Windows\SysWOW64\regsvr32 midas.dll
C:\Windows\SysWOW64\regsvr32 dbxora.dl
C:\Windows\System32\regsvr32 midas.dll
C:\Windows\System32\regsvr32 dbxora.dll
But for other 64 bit users I have not found the solution to the DBX error. The app always works correctly on Windows 32 bit. I have compiled the app in 64 bit as well, but some users still get the DBX error. Databases are oracle 12 and 19 connecting from windows clients to unix.
Related
What happens:
create delphi 32 bit application to open up a ms access database, the newer accdb one, created with access 2013 32 bit version. Using TADOConnection and dbgo. Works great.
Change to 64 bit platform, as soon as I try opening up a table at runtime, I get the "provider cannot be found error". Although I can open up a table within the IDE. OS is windows 10 pro 64 bit.
I have tried uninstalling ms office, and then downloading and installing the access 2013 database engine, the 64 bit version one. If I drop a TADOConnection on a new project, there are no MS ACE 12 or 15 providers. If I uninstall the 64 bit database engine, and install the 32 bit database engine, I see providers in both delphi 32 and 64 bit target platforms. I tried installing the 64 bit database engine using the "passive" parameter but microsoft has apparently caught on to this trick and will give the usual error message about you cannot install both 32 and 64 bit versions. So I tried using the 2010 versions of the database engines and still get error messages, although different ones.
It just feels like I'm missing something here. The weird thing is that in the IDE, using 32 bit access engine and 64 bit delphi target platform, I can make the connection active and open a table. But if I try and open a table at run time I get the error. I have also tried uninstalling and reinstalling delphi.
Ok so the short answer is yes it will work, but there are a few caveats:
You can only install either the 32 bit or 64 bit access 2013 engine drivers or Office, or any combination of those two. Microsoft has disabled the /passive or /quiet way to bypass that. So you can't install both 32 bit and 64 bit at the same time. (at least in a straightforward manner) You can go to control panel and see which ODBC drivers are installed via admin tools.
The IDE is 32 bit, and can only see 32 bit access engine providers when they are installed (via tadoconnect build data provider). Any 64 bit providers installed are not visible in the tadoconnect build connection string wizard.
The good news is that the 32 bit and 64 bit access engine providers have exactly the same provider name. So if you install the 32 bit drivers, create your 32 bit project, you can also create your 64 bit target as well.
with 32 bit drivers installed, your 32 bit target application will debug and run normally. If you try and run the 64 bit target, you'll get "provider not found"
with 64 bit drivers installed, your 64 bit target application will run normally, and the 32 bit application will give the "provider not found" error. In addition, in the IDE, you will not be able to see the data provider via the build connection string in tadoconnect, just leave it alone as it has the exact same name. You can run or debug your 64 bit app, just assume the data provider is correct even though you can't see it.
A thanks to Ken White for a point in the right direction.
I am having quite an issue trying to create a linked server in SQL 2014 to Informix. I have downloaded the IBM Informix SDK 4.10 FC2. This allowed me to create a 32 bit ODBC in the 64 bit ODBC tool and I was able to register the ifxoledbc.dll with regsvr32. However, I cannot get the ifxoledbc provider to show up under Server Objects -> Linked Servers -> Providers nor am I able to get the 64 bit ODBC set up under 64 bit. Every time I try to set up a linked server to the 32 bit ODBC I get an architecture mismatch error which I expect. I don't care whether I use the ifxoledbc driver directly for the linked server setup or use an ODBC connection for the linked server setup. Either one will work for my purposes of reading from the Informix database, but I just can't seem to get past the 64 bit crap!
Has anyone been able to set up a linked server to Informix on a 64 bit server?
I realize the question has already been posed here almost a year ago: ODBC connection from 64-bit SQL Server to Informix data source
But the answers to that question were not specific enough to help me. The guy who provided the screenshots did not say what he did to get the provider to show up.
I was going to post screenshots of the 64 bit ODBC showing that the DSN is 32 bit platform and a screenshot of the options I have when I try to add a new System DSN in the 64 bit version of ODBC (note that I cannot choose the IBM Informix ODBC Driver), but I don't have enough reputation points.
I finally fixed my own problem. The trick was to run the 64 bit SDK installer in compatibility mode on the server (by right-clicking on the installer and selecting "Troubleshoot Compatibility"). The installer then runs in Windows 7 mode and installs the ODBC drivers correctly. I did nothing to make the ifxoledbc provider show up under Linked Servers in SSMS. Once the ODBC was set up, I used that DSN to connect to the Cisco Informix database. I did not use the driver directly.
I installed the latest Chromium Embbed version on XE6, did a test using demo guiclient and worked very well. But when I create a new app and put TChromium component receive this error:
I did the tips on this question.
Usually that means that a 32 bit process is attempting to load a 64 bit module, or vice versa. You need to do a bit of debugging, for instance using Dependency Viewer, to work out which module has the wrong bitness.
One obvious possibility is that your host process is 64 bit and the CEF libraries are 32 bit. To fix that you would need to switch your process to be 32 bit, or find 64 bit CEF libraries. I'm not even sure if the latter exist.
I'm using Delphi XE2 in my system. When I'm trying to compile new Delphi 32 bit application I'm getting (cgrc.exe - Application Error) The application was unable to start correctly (0xc0000005). Click OK to close the application error. And I'm unable to create any applications with single Form either.
Based on Symantec forum there is a problem with Symantec Endpoinnt protection blocking cgrc.exe but only on 32 bit Windows. Same problem doesent ocurs on 64 bit Windows.
You can check their forums thread to get some more info on this: http://www.symantec.com/connect/forums/cgrcexe-resource-compiler-binder-cannot-run-windows-7-32bit
I searched around but I couldn't find a straight answer to these questions, only bits and pieces: if I install windows seven x64,
1 - will I be able to use delphi 2007+ as I'm used to aka start it, code in it, debug in it, compile in it ? I've seen the debugger issue and the hex edit workaround.
2 - will my application compiled in that environnement work on 32 bit versions of windows ?
3 - will my application I compiled with delphi on 32 bit windows work this 64 bit version ?
(of course all this is assuming "normal" applications as-in I don't expect things to work if I'm playing with pointers expecting them to be 32 bits long, obviously)
The overall question of this would be, as someone who is moving to windows seven 64 bits, will I be able to/should I use this as my main delphi developpement platform or will i be better off keeping a 32 bit boot for delphi dev ?
Thanks to anyone who can give me a clue about this
As Mason Wheeler stated, there's a problem with the 2007/2009 debugger and 64-bit platforms but it can easily be fixed.
I'm using D2007 (with this fix) on Windows 7 64-bit on a daily basis and it works just great.
There is now a hotfix for this.
No idea about Windows 7 64 bit version, but I have been using Delphi 4, 5, 2007 and 2009 for nearly a year now on Windows XP 64 bit, and given the effort Microsoft spends on backwards compatibility I don't see why things should be very different on Windows 7. This answers your last question - no need to keep a separate partition. Use virtualization for running things on a 32 bit system. Windows 7 does AFAIK offer you a virtualized Windows XP subsystem - at no cost, but you may need to download it separately.
Re 2. and 3.: The OS an application is compiled on does not matter for the deployment, as long as the compilation itself works. I have only ever been compiling 16 bit Delphi programs on 32 bit Windows versions, without problems. You should however always test on clean installations of your target OS versions, as a developer PC is sufficiently different from a user PC to not assume that everything will just work. This however is general advise, and has nothing to do with a 64 bit OS.
Your Delphi programs will run on a 32 bit layer (WOW64 - Windows on Windows 64) of Windows 64 bit which is close enough to the real 32 bit OS that you do not need to care about it, unless you work very closely with the lower system level.
I was doing some work on Delphi 2007 under Windows 7 64-bit yesterday, and it was a disaster. Every time I'd leave the program while debugging, either by quitting out normally or by stopping the debugger, it would raise an assertion failure that I couldn't get out of, bringing down the entire IDE. (This never happened under XP.) Apparently the WOW64 emulator isn't quite as stable as it ought to be... :(
If you're going to try to work on Windows 7 64-bit, I'd strongly recommend upgrading to Delphi 2010, which was built specifically with Windows 7 compliance in mind. If that's not an option, then at least install a VM with XP on it for your dev work.
Answers are:
1. Yes - With the workaround for the debugger issue
2. Yes - Delphi 2007 (native) will only build 32 bit applications
3. Yes - Unless it's a Device Driver or low-level service
First apply the patch as mentioned on Olaf's Blog. This fixes the debugger exit error.
Second, Install Windows XP Mode, which is a fully clean (and legal) windows XP 32bit virtual machine.
Compile application on Windows 7 64bit. Install onto the virtual machine. It should just work. Rinse, lather and repeat for other applications you are developing.
XP Mode is available to all owners of Windows 7 Professional and Ultimate editions. Don't know about corporate editions.
This is what I'm currently using for development as I had to perform an emergency OSectomy of a Macbook Pro
I run Delphi 2007 on Windows 7 Professional 64 bit and it was fine for a bit until a patch Tuesday a while ago. The IDE would die after throwing the debug error (SetThreadContext failed). I applied the patch found at http://cc.embarcadero.com/item/27521 and no more problems.
HTH. YMMV.
Doug
FYI, I am running Delphi 7 on Win7 64-bit. The trick to run this version is to NOT install to the Program Files(x86) folder - instead, install to something like C:\Delphi7. Been working with it this way for about a month now with a pretty heavy development load and it works great!