I have a Windows C++ application that builds into an excel plugin. My application links against the oracle 12 client, via OCCI (https://www.oracle.com/database/technologies/appdev/oci.html).
At runtime, the program will delay load oracle dll’s such as ocil.dll, oraons.dll, OraOCIEI12.dll.
Note that the dll’s are set to delay-load, because they are stored on a file server (not set in the user's windows PATH variable), and the first thing the program does, is to set this location.
We have users that combine our excel plugin with their own VBA code that uses an oracle ODBC driver. The problem is that none of our users have oracle 12 client installed on their own machines. They run oracle 11 client instead, and are not allowd to upgrade.
Oracle doesn’t have version dependencies in their names; both oracle 11 and 12 clients are dependent on oci.dll, oraons.dll, etc. The dll’s are version dependent, their names are not.
There are two kind of crashes:
First the user calls something via our library, and then via the external VBA code. What happens is that the oracle 12 dll’s are loaded first. Our library runs fine, but the VBA code crashes since it is trying to use the oracle 12 libraries.
First the user calls the VBA code, and then our library. The VBA code loads the oracle 11 dll’s and runs fine, but our library crashes.
Our application links to the SDK libraries downloaded from:
https://www.oracle.com/technetwork/topics/winsoft-085727.html
(instantclient-sdk-nt-12.2.0.1.0.zip)
Our application has to link to oracle 12, since we compile with Visual Studio 2017 and the MSCV 14.14 compiler.
Can I somehow make it work that I load both oracle clients?
I looked at the oracle header files, and nothing in there specifies the name of the dll’s that need loading. Our application links to oci.lib, and in there I can see multiple occurances of “OCI.dll”. Perhaps I could replace them with “OCI12.dll”?
I also found this page:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b3eaa07f-7f92-4693-8aa1-b8fee0b92d2f/cannot-load-2-dlls-with-same-name-but-different-versions
I tried it. When I do an explicit LoadLibraryA("oci.dll"), I can see in the debugger that I am loading the one that i set with the manifest. However, when I then make an actual function call that uses oracle, it is loading the ohter OCI.dll (on our file server), togehter with 3 other oracle dlls: oraocci12d.dll, OraOCIEi12,dll and oraons.dll. Maybe this has something to do with how oracle loads dlls?
For completeness, the user does something like this in his VBA code:
Dim cnnPointer As ADODB.Connection
cnnPointer.ConnectionString = "DRIVER={Oracle in 112};" _
& "DBQ=" & Me.txtMiljoe.Text & ";" _
& "UID=" & Me.txtUser.Text & ";" _
& "PWD=" & Me.txtPassword.Text & ";"
Thanks in advance.
Nele
Related
I try to index PDF files with Sitecore 7.
I installed IFilter , but I received on crawlers log next error :
ManagedPoolThread #17 09:24:20 WARN LuceneIndexOperations : Update : Could not build document data 4433434-3443-3223-91c4-233232. Skipping.
Exception: System.Runtime.InteropServices.COMException
Message: Error HRESULT E_FAIL has been returned from a call to a COM component.
Source: mscorlib
at System.Runtime.InteropServices.ComTypes.IPersistFile.Load(String pszFileName, Int32 dwMode)
at Sitecore.ContentSearch.Extracters.IFilterTextExtraction.FilterLoader.LoadAndInitIFilter(String fileName, String extension)
at Sitecore.ContentSearch.Extracters.IFilterTextExtraction.FilterReader..ctor(String fileName)
at Sitecore.ContentSearch.ComputedFields.MediaItemIFilterTextExtractor.ComputeFieldValue(IIndexable indexable)
at Sitecore.ContentSearch.ComputedFields.MediaItemContentExtractor.ComputeFieldValue(IIndexable indexable)
at Sitecore.ContentSearch.LuceneProvider.LuceneDocumentBuilder.AddComputedIndexFields()
at Sitecore.ContentSearch.LuceneProvider.LuceneIndexOperations.GetIndexData(IIndexable indexable, IIndexable latestVersion, IProviderUpdateContext context)
at Sitecore.ContentSearch.LuceneProvider.LuceneIndexOperations.BuildDataToIndex(IProviderUpdateContext context, IIndexable version, IIndexable latestVersion)
at Sitecore.ContentSearch.LuceneProvider.LuceneIndexOperations.<>c__DisplayClass7.<Update>b__0(Item version)
What I have to do work because on Sitecore documentation they said it must work out of the box.
I had the same issue and I received from Sitecore support next response (it works fine after):
1) Copy all the Adobe iFilter .dll files into the "\System32\Inetsrv" folder. This is the working directory for IIS on Windows Server.
The Adobe iFilter .dll files are stored at the "C:\Program Files\Adobe\Adobe PDF iFilter 9 for 64-bit platforms\bin" folder by default.
Also you can use the "IFilter Explorer" tool to detect the folder where the .dll files are stored:
http://www.citeknet.com/Products/IFilters/IFilterExplorer/tabid/62/Default.aspx
For more details please see the screenshot:
http://screencast.com/t/xmWukanM+
2) Delete all the files under the "Website/App_Data/MediaCache" folder;
3) Rebuild the Sitecore Search Indexes (Sitecore -> Control Panel -> Indexing -> Indexing Manager);
4) Clear the Sitecore cache (the http://{hostname}/sitecore/admin/cache.aspx tool);
5) Restart the IIS;
Here is the solution I took since I didn't like the idea of coping iFilter related DLLs into the system path.
install Adobe IFilter 9 (I used this link). Note version 9 is essential as starting at version X they abandoned file based interface.
add filter location to the PATH environment variable. In my case it was %ProgramFiles%\Adobe\Adobe PDF iFilter 9 for 64-bit platforms\bin\.
run iisreset
go back to Sitecore app and run index rebuild for necessary indexes.
For your consideration:
while trying to resolve the issue I granted full access to IFilter folder for app pool account. I don't think it's necessary as I removed it at the end and everything was still working fine.
After these steps PDF indexing started working fine on my instance of Sitecore 7 running on Windows 8.1.
Trying to run some of the desktop(AIR) samples located here
http://code.google.com/p/facebook-actionscript-api/
No matter what I try get the error message
Process terminated without establishing connection to debugger.
application descriptor not found
But as far as I can tell there IS a proper descriptor file (XML) present in my bin-debug folder.
Anyone have an idea what is happening? Could the issue have something to do with the Flexsdk I am using (4.6) when combined with the latest AIR 3.4?
This is my application descriptor file WITHOUT most of the commented code
<id>MediaUploadDemo</id>
<filename>MediaUploadDemo</filename>
<name>MediaUploadDemo</name>
<version>v1</version>
<initialWindow>
<content>MediaUploadDemo.swf</content>
</initialWindow>
Found most of my answers here
http://alpha-beta-pruning.blogspot.ca/2011/06/migrating-flex-3-project-to-flex-45.html
Key paragraph
'Each AIR sdk tends to have it's own application descriptor file formatting which means that an application that was created with AIR 2.0 must "migrate" its descriptor file to the new AIR 2.7 sdk. My suggestion is creating from scratch a new project that targets the new sdk, just so we can take its descriptor file, copy/paste it to our "old" project and change the necessary values to adapt our project (such as project name, etc).'
I am busy converting by existing firebreath plugin here to use gpgme instead of making calls via the OS and the gpg binary.
I have managed to get the code to compile in windows using VS 2010 on a x32 system but after loading the plugin into chrome I can not access the npapi code at all. Even simple version calls fails.
When loading the plugin I get no visible errors but when using sawbuck log viewer for chrome I get the erorr messages below.
.\renderer\webplugin_delegate_proxy.cc 347 PluginMsg_Init returned false
..\plugins\npapi\webplugin_impl.cc 271 Couldn't initialize plug-in
I have tried to use my code with both firebreath 1.4 and 1.6 and neither versions work. After some simple debugging it seems that using any code provided by gpgme (whether its called or not) causes the plugin to break.
I came to this conclusion by doing the following.
Created a new project with firebreath (versions 1.4 and 1.6)
Add the gpgme.h headers to gmailGPGAPI.cpp and changed nothing else aside from adding the required reference paths to the project.
Build the project to create the dll (this generates the dll fine).
Replace the existing ddl in my project with the dll in step 2 and test it with the following piece of code
plugin = document.createElement('object'); plugin.id = 'plugin';
plugin.type = 'application/x-gmailtest';
document.body.appendChild(plugin);
console.log("my plugin returned: "+ plugin.valid);
console.log("my plugin returned: " + plugin.version);
This returns valid = true and the version returns what ever i set it to.
I then modified gmailGPGAPI.cpp to now return the gpg version by calling gpgme_check_version(NULL) in the version method. I used that method because its probably the simplest returning function that I could test with.
Build the plugin and copy dll to chrome extension as in step 3-4. The plugin builds fine again as expected.
Load the plugin and try to execute the code in step 4 at which point it now just returns undefined for any property or method i try to access on the plugin. No errors are printed to the console or anywhere else in chrome except for the error logged to sawbuck.
I have got no idea where to look or what to try since I cant seem to get an actionable error to work against. I have also reduced by test code to the point where its just a new project with a one line change to make it easier to find the problem.
I should note the code in the repo builds fine in linux/OSX and loads into chrome correctly so I know at some level my code does work.
Two possible paths:
You may have a DLL dependency that isn't available which keeps the plugin from loading; if you run regsvr32 on it in the state where it doesn't work on chrome, does it work?
Your plugin may be loading and then crashing. Start chrome with --plugin-startup-dialog and then when it pops up a dialog warning you that a plugin is about to be loaded attach to that process and see if the process crashes. At this point you can also set breakpoints to try to figure out how far it gets.
Double check your metadata in PluginConfig.cmake as well; sometimes unusual characters in some fields can cause issues like this.
I have a Qt 4 application that is trying to connect to an MS SQL Server 2008 database using the Qt ODBC driver. The application runs fine when it is running in Windows; however, the target OS for the application is to have it run in GNU/Linux. When the application runs in GNU/Linux I get the following error:
QSqlError(0, "QODBC3: Unable to connect", " [unixODBC][Driver Manager]Data source name not found, and no default driver specified")
Is there something I need to configure on the SQL server or application side to get the connection to work?
I don't really know much about unixODBC, but have a look here:
unixodbc.org/doc/
For connecting to MSSQL, the following might be useful:
http://www.unixodbc.org/doc/FreeTDS.html
or .../FreeTDS2.html
Try to copy the odbc.ini file in ~/.odbc.ini . If not working again, try to copy the same file into /etc/odbc.ini. If this is not working, as these directories are different for different Unix systems, find all files: *odbc*\.ini and see if some of them are empty. If so, replace them with the correct .ini file.
I had the same problem and this solved it. But it's a really stupid solution, so I'm looking for a better one. Hope that helped (:
I have a batch file that tries to compile a static library using Borland C++ Builder 6.0
It is called from Borland make (makefile created with bpr2mak) which is called from a .bat file (used to compile the whole project with Visual Studio and some Borland C++ Builder legacy projects), which is called from a bash shell script running inside Cygwin.
When I run the .bat file directly from a Cygwin shell, it runs OK, but when its being run from a Program calling cygwin with Boost::Process::launcher I'm getting this error:
C:\ARQUIV~1\Borland\CBUILD~1\Bin\..\BIN\TLib /u bclibs.lib #MAKE0000.###
DOS-reported error: Bad file number
TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
opening 'MAKE0000.###'
** error 1 ** deleting bclibs.lib
It's a complicated scenario, but this Program which calls cygwin is run whenever we need to build our software package which needs to be build for various Linux distos and Windows 32 and 64-bit.
Note: It's the only Borland Project failing, the other compile just fine (it's the only static library using borland also, so it can be some problem with the TLib tool.
The problem was that TLib does not like to have his output redirected (seen here) without having an input pipe as well. Solved by creating an input pipe to in the Boost::Process::launcher using set_stdin_behavior
I'm just guessing here, but this may have to do with long filenames and/or spaces in paths.
1) Modify your makefile so it would save current environment to a file, immediately before executing the failing command (set > d:\env.txt & echo CD=%CD% >> d:\env.txt). Then run it both ways (directly and via program) and compare the environments of good run and bad run.
2) Using filemon from Sysinternals, capture logs of disk access in both cases (these logs are going to be huge, though you can uncheck everything except Open in the filter to reduce the size). Again, compare and check for clues...
3) Try instaling everything involved to paths conforming to 8.3 scheme.
This error is not related to C++ itself. It happens when your build script opens too much files (more than defined in DOS command processor environment). To resolve this issue try to set value of files variable to 253. For Windows XP this variable defined in the file %WINDIR%\system32\config.nt.
files=253
Seems it is known bug in Borland C++ tools. Here is description and possible workaround for this issue:
Problem: Some static Lib projects will
not link correctly when compiled. You might see something
like this :
J:\Borland\CBUILD~1\bin\..\BIN\TLib /u debug\jpegD.lib #MAKE0000.###
DOS-reported error: Bad file number
TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
opening 'MAKE0000.###'
** error 1 ** deleting debug\jpegD.lib
MAKE failed, returned : 1
Workaround : In some cases (where the "Bad file number" error is seen) it may be possible to work around this by specifying -tDEFLIB.BMK in the BPR2MAKE Options field, and Turning off the "Capture Make Output" option.
I have not tested it, but I hope that helps.