64 bits alternatives to linq to excel - asp.net-mvc-3

I have an ASP.NET MVC 3 application in which I want to import excel files.
I managed to do this using the linq-to-excel library. But when I deployed the application on IIS I got an error which turned out to be caused by IIS being running on 64bits system.
This can be solved by enabling the 32-bits applications option for the pool in IIS.
Will this affect the performance of the application? If yes, is there another alternative to linq-to-excel that works on 64-bits.

https://code.google.com/p/linqtoexcel/wiki/UsingLinqToExcel
x64 Support
If you want LinqToExcel to run in a 64 bit application,
make sure to use the 64 bit version of the library.
You will also need to make sure to have the 64 bit version of the
Access Database Engine installed on the computer.
And make sure you manually set the DatabaseEngine property to
DatabaseEngine.Ace
var excel = new ExcelQueryFactory("excelFileName");
excel.DatabaseEngine = DatabaseEngine.Ace;

Related

VB6 application oracle 12 64bit connection

We have a number of applications written in VB6 (not .NET) that have been running for almost 20 years.
These applications are running on Windows 2007 64bit servers and connecting to Oracle-11 with a 32bit client.
The connection string contains "Provider=OraOLEDB.Oracle"
So far, so good.
The problem is that we need to convert, for reasons that go beyond the scope of this thread) to Oracle-12 64bit.
After having installed the Oracle 12-client (and disinstalled the Oracle-11 client), we get the following error when trying to open the connection:
"Provider cannot be found. It may not be properly installed."
I'm sure we did install the client and am therefore afraid that VB6 cannot connect to Oracle using the 64bit client.
Apparently easy solutions are unfortunately out of the question:
- Convert to .NET or whatsoever and compile under 64 bit
- Keep the 32bit oracle client.
Any idea how to risolve this?
OLE-DB
Good news and bad; because Visual Basic 6.0 is a 32 bit program with no 64 bit compiler, the 32 bit Oracle Data Access Components software must be installed, even if the database itself is running on a 64 bit server in a 64 bit Oracle Database install, specifically you need the 32 bit Oracle Provider for OLE DB rather than the whole client.
The driver can be found here (Download the ODAC XCopy version):
http://www.oracle.com/technetwork/database/windows/downloads/utilsoft-087491.html
The following thread describes your exact problem and instructions on fixing it:
https://hoopercharles.wordpress.com/2012/11/25/connecting-to-an-oracle-database-with-visual-basic-6-0-on-windows-8-64-bit/
ODBC drivers
Another way to connect is to use ODBC drivers instead, there are pros and cons to each method so google to find them.
First you'll need to install the SQORA32 ODBC driver which comes with the 64 bit client or with the ODAC linked above.
Next, you'll need to create an ODBC connection, instructions can be found here:
https://tensix.com/2012/06/setting-up-an-oracle-odbc-driver-and-data-source/
Finally you need to change your connections strings in VB6 to use the newly created ODBC connections. Something along the lines of the following should work nicely (obviously nameOfDatabase is the name given to your odbc connection):
Provider=MSDASQL;Dsn=nameOfDatabase;Uid=usernameHere;Pwd=passwordHere
Be careful when you set up your DSN, make sure you use the 32 bit ODBC connection manager which can be found in the following location:
c:\windows\sysWOW64\odbcad32.exe
The same program can be found in the system32 folder but that's the 64 bit version....not confusing at all!
(If you can't follow the solution of twoleggedhorse, which is way better.)
You can write a small DLL in .NET 32bit, and make it COM visible so it will be usable by your 32 bits application.
I said in my comment that it seems to be possible in .NET to talk with the DB without an installed client.
To make it through the least painful, you can write it ADO-like (ie a class to replace RecordSet, another for Connection, and so on). Then add it as a reference to your projects and perform a search/replace.

How to install ColdFusion 9 in Windows 10 (IIS 10)

I'm wondering if anyone has ever figured out a way to install ColdFusion 9 in Windows 10 (IIS 10)? I understand CF 9 is not officially supported in Windows 10 / IIS 10, but I'm wondering if there is some clever way to make this work? Our ColdFusion production server is hosted by our ISP and we are unable to upgrade ColdFusion at this time, so I'm stuck with CF 9 for now. I would very much like to be able to continue to develop and test in the same version as our production server, and my new development machine is Windows 10.
I tried the CF 9 installer, chose the developer option, and got no errors until I got to the step where the installer wants to load the ColdFusion administrator page to complete the setup process where I promptly get a 404.3 not found error. I tried rebooting the machine, went to the CF admin and same results. After some further looking into this, I believe the issue was that the IIS handlers never got installed, so IIS did not know what to do with a CFM file. So even though the Admin files exist on the server, IIS doesn't know how to serve them to the browser.
When I try to use the Web Server Configuration Tool to set up IIS, it looks like it could work until I try to add all IIS websites and click OK at which point I get the error "Version 10.0 is installed. Supported versions are 4.x, 5.x, 6.x, 7.x". So might there be a way to fool the WSC Tool into thinking that IIS 10 is in fact IIS 7 or is that not going to help? I did take the step of adding the IIS 6-related management tools thinking that would allow the CF 9 installer to work with IIS 10 (this seemed to be necessary for IIS 7.x).
I have had a bit more luck running the 32-bit version of the installer, and trying to set it up with an Apache server instead of IIS, and it seemed to almost work but I am unable to create CF data sources using the ColdFusion admin, I get an error when I try to add a data source. It may have to do with some confusion about 32-bit versus 64-bit data sources, so I'll try to troubleshoot this approach some more.
Thanks in advance for any ideas/suggestions.

PDFCreator and VB6 on 64-bit: ActiveX component can't create object

I'm using PDFCreator to create PDFs in VB6. My VB6 development VM is Windows XP 32-bit. On that system PDF generation works both from a desktop app and from ASP (via VB web class runtime).
When I create an exe to run on Windows 7 or Windows Server 2008 R2 or use it in the web class runtime I get:
Run-time error '429':
ActiveX component can't create object
This is when using early binding. I add a project reference to "C:\Program Files\PDFCreator\PDFCreator.exe" and then in my code I do:
Public WithEvents mPDFCreator As PDFCreator.clsPDFCreator
Set mPDFCreator = New PDFCreator.clsPDFCreator
If I don't use a project references and use late binding instead, then it works on the desktop app but still not in the web class runtime. Late binding is done like so:
Set mPDFCreator = CreateObject("PDFCreator.clsPDFCreator")
I want to use early binding so that I can use the events, plus I need it to work in ASP/Web Class Runtime.
I realise I'm dealing with ancient technologies here and I should have tempered expectations when running such things on modern 64-bit Windows and IIS. If porting this legacy app to .NET were an option, I would.
On IIS I have set the Enable 32-bit Applications setting on my app pool. I have also tried running it as Administrator to rule-out security problems.
I've done everything I know how to debug this, but I'm stumped. I suspect it has something to do with PDFCreator being a 32-bit app and COM registration. I've also tried running regsvr32 out of SYSWOW64 but PDFCreator.exe can't be registered.
Windows 64-bit architecture does not allow the load of 32-bit dll into 64-bit processes.
But you can modify the configuration of your vb project to convert it from an in-process dll COM component into an out-of-process exe COM server. This will allow you to instantiate your 32-bit component from a 64-bit process.
See Process Interoperability
Since this is a VB6 question there aren't any 64-bit processes to worry about.
It seems far more likely than anything else that this library just isn't being registered properly. I haven't use it since I don't know whether its setup works properly. I do know that the download itself does not display with a UAC Shield on its icon, suspicious in itself. For all I know the setup program spawns a run of the wrong regsvr32.exe.
But it seems more likely you have misregistered the library manually after copying it naked over to these 64-bit Win7/Server 2008 systems.
In any case, going over all of the symptoms you describe, I'd guess it got registered as a 32-bit ActiveX library but registered in the per-user virtualized part of the registry for the user you were logged on as when you registered it.
This can be a hassle to clean up after. However you should, and then be sure to manually run the original setup once again with elevation.
These threads that include hand-wringing over "ancient technologies" really get old. It's a poor workman who blames his tools. In the future why not hire an experienced programmer to handle tasks like this?
I use PDFCreator in my accounting software written in VB6. Years ago, I noticed that after a certain update from the makers of PDFCreator, my software stopped working properly with it. The problem stopped after I re-installed the older version, and came back when yet another new update was released from them, so I have had my customers freeze at the version that worked. I don't know off the top of my head what version that was, but I can check my own web site since I made it downloadable for my customers if it would help, but it's likely many years old now.

Using Internet Transfer in windows 7

I am developing a portable application in VB6.
My target platforms are Win XP - Vista - 7 - 8 ( I think all of them Have VB6 Run.
I one part of My application , I need to read a small text file form Internet
I used
Inet.OpenURL
And this is working well in Win Xp , But in Win7 I got this error
Run time error ‘339’: Component ‘MSINET.OCX’ or one of its
dependencies not correctly registered: a file is missing or invalid.
As this is a portable application , I can't make a Setup file.
What Can I do?
Is it possible to include MSINET.OCX in my application file?
Is there any replacement for Inet.OpenURL Which works in Win 7 ?
Thanks
For something this simple you can use the MSXML XmlHttpRequest object instead. Version 3.0 should be present as part of Windows in nearly any version (even back to Win95 if IE 5.x was ever installed).
This is generally a cleaner option then the Internet Transfer Control as long as you don't need FTP but only HTTP/HTTPS. It can also be used for async requests if you deal with its script-style event binding.
If you are only doing simple GET requests you can simply use the AsyncRead method that is built into the VB6 runtime.

Microsoft Access 2007 accdr extension an Vista 64 bit OS

Has anyone ever tested a Microsoft Access 2007 .accdr application on Windows Vista 64 bit version? I sell a shareware program using the Access 2007 runtime, and, for one customer with that setup, there's some kind of problem. According the user ". When I try to execute the program, it opens IE and then brings up the dialog box to either Open, Save, or Cancel the "myprogram.accdr" file. If I choose run it simply goes away and then returns back to the same question"
It sound like this somehow got mapped to IE. On my windows XP system, it starts Access and runs the program. Any ideas?
MS Access isn't supported on 64bit, as it requires a 64bit JET engine which isn't available, Microsoft only released a 32bit JET engine. So your application has to run on WOW so it runs as 32bit and therefore is able to use the 32bit jet engine.
It works just fine. After 3 weeks of hair pulling with access installer packager. I got it wot work. your references must be added in the packager or you will get run time errors. Billions of them.. Not really 4 or 5. and then it will not recognize the built in functions like date, time, isloaded....etc.
SO YES IT WILL WORK.
Is the customer using the 64 bit IE? Access 2007 is 32 bit only. The 32 bit IE might work properly.

Resources