I'm developing an Web Application (C#) on a Windows 7 Enterprise (x64), with Office 2007 using Visual Web Developper 2010 Express. On that project that reads information from Excel files like so:
protected void Page_Load(object sender, EventArgs e)
{
string connString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\\1.xlsx;Extended Properties=\"Excel 12.0;HDR=YES;IMEX=1\"";
OleDbConnection oleDbConn = new OleDbConnection(connString);
try
{
oleDbConn.Open();
OleDbCommand oleDbComm = new OleDbCommand("SELECT * FROM [Sheet1$]", oleDbConn);
OleDbDataAdapter oleDbDtAdapter = new OleDbDataAdapter();
oleDbDtAdapter.SelectCommand = oleDbComm;
oleDbConn.Close();
}
catch (Exception evt)
{
Response.Write("ERRO: " + evt.Message.ToString());
}
}
On the development PC everything works as it should and I am able to open both XLS and XLSX Files.
Now, passing this simple code to my deployment server wich has Windows Server 2003 R2 Standard X64 Edition (SP2) I had to install Access Database Engine 2007 (only for x86) since there was no Office 2007 on the server, so after the instalation, and deploying this simple code to the server I got IErrorInfo.GetDescription failed with E_FAIL(0x80004005) error.
Some more searching and I found out that there was an Access Database Engine 2010, this time for bot x86 and x64 architectures so I thought duuhhh now It's gona work.
After installing Access Database Engine 2010 voila I was able to access XLS file but for XLSX I'm now getting this crazy error:
External table is not in the expected format
I've been banging my head for almost a day now, but still can't understand why this is happening!
I fixed the "External table is not in the expected format" error by installing Microsoft Office Access Runtime and Data Connectivity 2007 Service Pack 2 (SP2)
I had this same issue on a local pc (Using the ACE.OLEDB) and what resolved it for me was this link:
http://support.microsoft.com/kb/2459087
The gist of it is that installing multiple office versions and various office sdk's, assemblies, etc. had led to the ACEOleDB.dll reference in the registry pointing to the OFFICE12 folder instead of OFFICE14 in
C:\Program Files\Common Files\Microsoft Shared\OFFICE14\ACEOLEDB.DLL
From the link:
Alternatively, you can modify the registry key changing the dll path to match that of your Access version.
Access 2007 should use OFFICE12, Access 2010 - OFFICE14 and Access
2013 - OFFICE15
(OS: 64bit Office: 64bit) or (OS: 32bit Office: 32bit)
Key: HKCR\CLSID{3BE786A0-0366-4F5C-9434-25CF162E475E}\InprocServer32\
Value Name: (Default)
Value Data: C:\Program Files\Common Files\Microsoft
Shared\OFFICE14\ACEOLEDB.DLL
(OS: 64bit Office: 32bit)
Key:
HKCR\Wow6432Node\CLSID{3BE786A0-0366-4F5C-9434-25CF162E475E}\InprocServer32\
Value Name: (Default)
Value Data: C:\Program Files (x86)\Common Files\Microsoft
Shared\OFFICE14\ACEOLEDB.DLL
Related
On a new Windows Server 2016 PC:
signed on as administrator
Fresh install of 19c with default orcl database. No issues during install
Installed full 32-bit 11g client (needed for connection to legacy app) no install issues
added SQLNET.ALLOWED_LOGON_VERSION_SERVER = 11 to sqlnet.ora
tnsping orcl ran and showed connection
sqlplus /nolog
connect / as sysadm
returned ORA-12560 TNS Adapter: protocol adapter error
Both listener and orcl services are running (tried restarting them but still got error)
Tried setting $TNS_ADMIN and $ORACLE_HOME but error still occurs.
Tried rebooting but no change.
PATH has client oci.dll folder listed first then ORACLE HOME folder
Pulling hair out has commenced...
I'm new to Oracle database, but I had a similar problem while installing Oracle 21DB express. I kept installing and uninstalling because I could not get past the login/password. It kept giving me
"ORA-12560 TNS Adapter: protocol adapter error"
what I finally did was on my last installation, on the setup.exe, you must right click on the mouse and "run as administrator". Then everything ran perfectly. Also while researching I was told don't have more than 1 version of SQL on a machine.
I'm working on a project to write invoices to an excel workbook in PeopleSoft 9.2 using PeopleTools 8.54. In our old version (8.49) we did this:
&oWorkApp_Inv = CreateObject("COM", "Excel.Application");
&oWorkApp_Inv.DisplayAlerts = "False";
&oWorkBook_Inv = ObjectGetProperty(&oWorkApp_Inv, "Workbooks");
Doing the same in 8.54, I get an error that the application class COM is not found. I've researched through PeopleBooks and it suggested doing exactly what I'm doing, even with COM as the class. What can I do to fix this, and in what package can I find COM?
The two requirements for using the COM object are:
The server is running Windows
Excel is installed on the server
I created an App Engine is 8.54.13 and it ran successfully on my PSNT process scheduler.
Local object &excel;
&excel = CreateObject("COM", "Excel.Application");
&excel.quit();
I have created a C# console project using Visual Studio 2008 and OracleClient (OCI) libraries to connect to a Oracle 11g database. This code works in Windows. I copied the whole project into Linux and Open the solution using MonoDevelop 4.2.3. But while running the project, the Database Open call throws an exception
string connectionString = "Data Source=Test; User ID=UID; Password=PWD"
OracleConnection conn = new OracleConnection()
conn.ConnectionString = connectionString;
conn.Open();
Exception:
System.DllNotFoundException: libclntsh.so at (wrapper
managed-to-native)
System.Data.OracleClient.Oci.OciCalls/OciNativeCalls:OCIEnvCreate
The libclntsh.so file is under the location /home/dbuser/instantclient_12_1
I have set the environment variable by adding the below in the /home/dbuser/.bashrc file and rebooted the system.
export
LD_LIBRARY_PATH=/home/dbuser/instantclient_12_1:$LD_LIBRARY_PATH
But still I am getting the same error. I couldn't find any option to include the Libraries in the MonoDevelop.
Thanks
Looks like LD_LIBRARY_PATH environment variable is not set up correctly or does not get applied.
Try creating additional linker configuration file instead with the following command:
echo /home/dbuser/instantclient_12_1 > /etc/ld.so.conf.d/instantclient.conf
Then as root update linker cache with command:
ldconfig
Restart MonoDevelop and try again.
I have resolved the issue by doing the following
echo $ORACLE_HOME/lib > /etc/ld.so.conf.d/dbconf.conf
set the$ORACLE_HOME, $ORACLE_INCLUDE_PATH and $ORACLE_LIB_PATH to
/etc/profile.d
Because of some reason MonoDevelop IDE is not picking the library libclntsh.so if I use the OCI client libraries
I would like to analyse a DLL from within a T4 template using Reflection, so that I can generate code based on the results of the reflection analysis. I know EnvDTE would be a better option, but this is not possible in my case for several reasons.
The problem with reflection is that the DLL is a 64-bit DLL and if I load that within the T4 template I get a BadImageFormatException because I am trying to load a 64-bit DLL into a 32-bit process (Visual Studio 2012).
Is there any way to analyse the contents of that DLL within T4, preferrably using reflection?
I have already thought about writing a console application which analyses the DLL, writes the results to an XML file which is then consumed by the T4 template, but that is not really my favorite solution...
BTW: The DLL is a managed C++ DLL. So Roslyn is no option either because it only supports C# and VB).
A thing worth testing is that if loading an assembly for reflection only works for you. I did experiment a bit and it seems it succeeds loading a 64bit assembly into a 32bit process then. It can't execute obviously but that should be ok for you if I understood you correctly:
For the full sample look at: https://github.com/mrange/CodeStack/tree/master/q18985529/Reflect
var assembly = Assembly.ReflectionOnlyLoad ("X64");
var types = assembly.GetTypes ();
foreach (var type in types)
{
Console.WriteLine (type.FullName);
foreach (var field in type.GetFields ())
{
Console.WriteLine (" {0} {1}", field.FieldType, field.Name);
}
foreach (var property in type.GetProperties ())
{
Console.WriteLine (" {0} {1}", property.PropertyType, property.Name);
}
}
Loading for ReflectionOnly has some drawbacks IIRC but sometimes it's worth it.
You can also try to modify T4VSHostProcess.exe to run as 64 bit process by running corflags T4VSHostProcess.exe /32BITREQ- /Force. But this modification will repair situation on PC where you made this modification. Also be sure what you are doing (backup, try outside of Program Files, etc.).
Backup your T4VSHostProcess.exe file. To avoid access rights problems, copy your T4VSHostProcess.exe process to some folder outside Program Files. Run the following command and then copy T4VSHostProcess.exe for original folder.
C:\Tools\T4>corflags T4VSHostProcess.exe /32BITREQ- /Force
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.6.1590.0
Copyright (c) Microsoft Corporation. All rights reserved.
corflags : warning CF011 : The specified file is strong name signed. Using /Force will invalidate the signature of this image and will require the assembly to be resigned.
You can ignore warning from CorFlags tool.
You can make sure what flags has been set for T4VSHostProcess.exe by running corflags T4VSHostProcess.exe without options.
Before:
C:\Tools\T4>corflags T4VSHostProcess.exe
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.6.1590.0
Copyright (c) Microsoft Corporation. All rights reserved.
Version : v4.0.30319
CLR Header: 2.5
PE : PE32
CorFlags : 0xb
ILONLY : 1
32BITREQ : 1
32BITPREF : 0
Signed : 1
After:
C:\Tools\T4>corflags T4VSHostProcess.exe
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.6.1590.0
Copyright (c) Microsoft Corporation. All rights reserved.
Version : v4.0.30319
CLR Header: 2.5
PE : PE32
CorFlags : 0x9
ILONLY : 1
32BITREQ : 0
32BITPREF : 0
Signed : 1
I have a simple program to test opening a connection to excel file using ADODB.
This is ASP Classic using VBScript.
Here is the code:
<%# Language="VBScript" %>
<% Response.buffer = true %>
<html>
<body>
<%
'Name of the excel file
exceldb="AW_Test.xls"
excel_file_name=Server.MapPath(exceldb)
response.write(excel_file_name)
Set cn = Server.CreateObject("ADODB.Connection")
cn.Open "Driver={Microsoft Excel Driver (*.xls)}; DriverId=790; DBQ=" &excel_file_name & ";"
cn.Close
Set cn=Nothing
Response.Write("All is good in the world...")
%>
</body>
</html>
When trying to run on this configuration:
Windows 7 64bit
IIS 7
Application Pool in 32 bit mode
Files in root directory
Running on Local Host [http://localhost/adotest.asp]
I get the following results:
C:\inetpub\wwwroot\AW_Test.xls
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Excel Driver] The Microsoft Jet database engine cannot open the file '(unknown)'. It is already opened exclusively by another user, or you need permission to view its data.
/adotest2.asp, line 13
However, on the same machine under this configuration:
Virtual PC in XP Mode
IIS 6
Files in root directory
Running on Local Host [http://localhost/adotest.asp]
I get the following results:
c:\inetpub\wwwroot\AW_Test.xls
All is good in the world...
Things I have verified/tried:
Verified permissions (note this is the root directory)
Tried using the Jet Engine instead with
cn.Open 'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Inetpub\WWWRoot\AW_Test.xls;Extended Properties="Excel 8.0;HDR=No"'
Got error:
C:\inetpub\wwwroot\AW_Test.xls
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
/adotest3.asp, line 13
Verified ALL application pools running in 32 bit mode
Verified drivers exist in SYSWOW side of data sources
I am sure I am missing something simple but, I am about out of things to try.
I know there are much better ways than ASP Classic etc. but, this should still work...
I appreciate any help...
Try with just:
cn.Open "Driver={Microsoft Excel Driver (*.xls)}; DBQ=" &excel_file_name & ";"
It should work..