Dear Experts : I have an existing MS Access database , and I have created a web API using Visual Studio 2019. I am trying to create an ADO.net entity data model or even Code first . The problem is that I cannot find in the data source when I create new data source , the oledb .
Any idea how to connect to Access via API
Thanks in-advance
Do you have the Access database engine installed?
I would install the Access database engine from here:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
Make sure you choose the correct bit size. If you running the web server as x32 bits (the default), then install Access x32 (x86) version. If you are running your .net application as x64 bits, then install the x64 bit version of Access. Keep in mind that Visual Studio is a x32 bit application. So, if you choose "any" CPU, it will launch your application as x32 bits.
If you force your project to x64, then you need to have installed the x64 bit version of the Access database engine. Keep in mind that running as x64 bits will work for debug, and running and testing. However, while you can use the connection builders in VS, the final test connection will ALWAYS fail if you using the x64 bit version of Access. This is because VS is a x32 bit application. So, the test connection button will not work, and if you going to use the dataset designer (or now the newer version (entity frame work), then you best develop with the x32 bit version of Access.
If you just developing local, then not a problem, but most hosted web sites (in fact near all) are x64 bits). If you not using the IIS express local, then you have to force your project to x64 bits. And testing connections to the database will be a challenge (your code, or debug code will work, but actual test connections from VS will fail if your project is forced as x64 bits.
Related
I have a new VM on which I have installed Visual studio.
I created a new SSIS project, and am trying to use the oledb data source task to access an .accdb MS-Access file.
However I cannot see the Provider. So I installed the Access 32 bit runtime. Now I can see the provider. I am reading that since visual studio is a 32-bit tool, we have to install the Access 32bit runtime. Otherwise if we install the 64bit runtime, then we will not be able to see the provider in the list because visual studio is 32bit and only shows 32bit providers.
When I hit the debug button in visual studio SSIS project it can access the MS-Access file. I am now confused and want to ask - when the project is running, does it run in 32 or 64 bit mode? If the answer is 64bit mode, then how can it access the MS-access file using the 32bit provider? Does it mean that project running in 64 bit mode can utilize 32 bit mode runtime/provider?
Assuming no settings are changed, when debug button is pressed, then does the program execute is 32 or 64 bit mode? Does the OS bitness have any impact on this?
You are quite right and quite close here.
Since Visual Studio is x32 bits?
Well, if your project is set to x86 (x32 bits) or set to ANY CPU?
Then hitting F5 to run + debug (or ctrl-F5 to run the .exe without debug), then you will get (have) a x32 bit running program. Some caution here. If you use ANY cpu? then again FROM VS f5 to run - you get a x32 bit process.
But, if you go to the windows commnd line?
Well, if you launch teh windows x64 bit command line (default on most computers), then if the project is ANY cpu? Then your app run will be x64 bits. (and ANY un-manged code such as Access, or any other windows code used for COM autoamtion? it will break.
If you launch the windows x32 bit command line (with any CPU) then you get a x32 bit version running.
So, from VS - F5 - always x32 bits.
From windows command line - depends.
So, what above suggests? Well, if your intention is to have + use x32 bits process? Then FORCE/SET the project to your intentions. That way, no "by chance" will fool you, and your application will ALWAYS run as to the project settings.
So, in such cases, I do avoid ANY CPU.
Now, what happens if you force the project to x64 bits? eg this:
Well, if you pick x64 bits? (and not any cpu, and not x86).
Then hitting f5 (or ctrl-F5), it WILL run the application as a x64 bits in-process. I am not sure quite how VS works, but they have some kind of "bridge" that marshals the x64 bit debugger to talk to VS x32 bits.
So, if you force the project to x64, then it will always run as x64 bit - including from VS.
So, this means:
if you set project to x64 bits - use a connection builder in settings?
You can use the connection builder but since (we assume) that you using
access x64 bits? Then the test connection button in VS will NEVER work.
But, if you run the code as x64, and have access x64, then it will work. So ONLY the test connection button fails - and that's due to VS being x32.
If you have even the wrong version of Access (say x32 bits), and your project is set to x64? Then the connection builders will work and EVEN the test connection will work (because test connection is ALWAYS x32 bits from VS). This has the effect of you building a connection, hitting test connection - it says good!!! But when you run the project (f5, ctrl-f5), the project runs as x64, and it will fail (this example assumes x32 bits).
Now this is building an writing code from VS. I don't' know of a SSIS package built with Visual Studio works different. But we do NOT want to confuse Visual Studio (VS) with that of say sql studio or other systems - they don't have the project "cpu" or "bit" setting options like you do for a VS project.
So, I quite much suggest if your intention is x32 bit operations, then ALWAYS force the VS project to x32 bits, and thus come time to launch that .exe from windows, then it will never run with a wrong or un-expected bit size.
I not tested a SISIS integration project, but if building this from VS? Then once again, force/set the project bit size.
In effect to remove the "chance" of the wrong bit size? Then force the project to the given bit size you as the developer were intending to use here - that way this is not left to chance.
There ARE times when you want to use ANY cpu. A really good example is when you build say class library code to share amoung projects. In that case, ANY cpu is a good choice, since then EVEN projects forced to x32 or x64 can referances those external assemblies and library code.
However, if you force those external assemblies to a given bit size, then only projects running that that correct bit size can consume such libraries.
.net code (managed) is differnt then un-managed code. .net code has the ability to run "either" x32 or x64 if you choose ANY cpu. But un-managed code (external non .net code such as Access) can't change on the fly like .net code can. And I use the term "on the fly lose here". Since ONCE a .net program starts running x32 or x64? It remains that bit size until terminated.
So, ANY CPU is fine for external class library code you write and thus want to include in any project. But the main project .exe program has to use SOME external non .net (non managed) code? Then you would do very well to force the project bit size settings.
And to answer you last question?
If the provider is a .net one, such as sql provider or whatever? Then it is managed code - cpu settings don't matter. it is ONLY when you start using external code systems that are NOT managed and NOT .net code. MS-Access is one such common example. So would be any windows c++ or even a lot of commerial programs.
For example. Sage/Simply accoutning, and Quickbooks accounting? They offer .net SDK's to interface to those accoutning packages. But they only have x32 bit verisons of those desktop programs - and they are not .net prorgrams. So once agian, you do well to force the project to x32 bits.
So, no x64 bit process can consume a x32 bit process. nor can you consume external librares that don't match.
However, if that library code and system is .net (managed code), and was compiled and created with any CPU, then you don't have any restrictions in regards to using ANY cpu, or even consuming those libraires when you force the .net project cpu settings.
So this whole system ONLY breaks down when you introduce or start using external code libraires.
For example, if you use .net ghostscript library? They have two versions - x32 and x64. And thus just like MS-Access you have to match up the bit size of those external libraries.
This actually is a REALLY nasty problem say for Adobe PDF. Their pdf viewers are x32 only. In fact it was only what - last month they started offering x64 bit versions of their PDF adobe reader. And they no doubt started doing this since office is now moving towards being x64 bits and not a x32 bit system/program.
Is there any way to make my .NET application use either 32 bit or 64 bit reference, depending on whichever one is available on the running environment?
I've a MSIL built application that currently references the 32-bit version of Oracle.DataAccess, because that's the version installed on my machine. Problem is, some machines only have 64-bit Oracle.DataAccess installed. Is there a way to set my application so that it dynamically references the available dll, regardless of its word size?
Have you tried using the Managed Oracle Data Provider (ODP) for .NET driver? I use it for all my .NET (3.x and 4.x) applications that communicate with an Oracle database. It and the Oracle Instance Client are simple to install and use via XCOPY or NUGET.
I'm using the Oracle Data Access(ODP.NET) in a mvc3 project.
the odp.net has both x64 and x86 versions separately and i want to use the x64 version.
I set "Platform target" to x64 and add a reference to x64 version of odp.net, there is no problem to publish on iis server, but i can't run the project for develop and test, however Razor views display errors on c# statements.
How i can develop the project in x64 platform?
I would say the immediate problem is forcing your platform target to x64. The asp.net development server is 32 bit. Either leave it as "Any CPU" or run a 64 bit dev server (either the local IIS server or compile cassinidev as 64 bit). If you do leave it as any cpu so you can continue to use the out of the box dev server, you'll get the same error with the 64 bit version of oracle.dataaccess.dll for the exact same reason.
I install the 32 bit version on my machine (i also install the 64 bit version but I mention that only to note that they run fine side by side). The reference to Oracle.DataAccess.dll does not include bit-ness, only version. So as long as you have the same version (or later with publisher policies) of the 64 bit flavor on the server, everything will run fine once you deploy.
From the Oracle website here:
http://www.oracle.com/technetwork/database/windows/downloads/index-090165.html
This is for their latest Oracle Data Access Components, 64-bit ODAC 11.2 Release 4 (11.2.0.3.0) for Windows x64. I want to use the developer tools (ODT) but they aren't available in 64 bit (probably because VS2010 is still 32-bit). From the site:
Important: The 32-bit Oracle Developer Tools for Visual Studio download is required for Entity Framework design-time features. The above download fully supports Entity Framework deployment, but does not contain design-time tools.
I don't use EF (I use the Mindscape LightSpeed product as it's usually 3 or 4 years ahead of EF) but the principle is the same - VS2010 and LightSpeed are 32-bit apps and can't load/use x64 libs.
I would like to use the 32-bit tools (ODT) to develop my app and deploy the app using the x64 ODAC. Has anyone done this? Can it be done? Anybody?
If it matters, this is for a WCF service running on a virtual Windows Server 2008 R2 machine. What I have done semi-successfully is force everybody to 32-bit operation, but that seems a little silly if 64 bit is supported as they claim it is.
Thanks in advance,
Dave
What the Oracle site mentions is that they have provided the ODAC components for both 32 and 64 bit, but have the Visual Studio design tools for only 32 bit.
Since you are not using EF, I am guessing you are interested in using ODP.NET components with LightSpeed.
For this scenario, you could go ahead by installing both 64 and 32 bit of ODP.NET on the development system and allowing the application to run in native mode on the deployment systems (the application will select the 64 or 32 bit ODP component based on the platform it is running on).
Check RealFiction blog and Semaphoremd blog for detail about installing the client tools for both 64 and 32 bit in parallel. Basically proper way to go about installing them in separate folders and creating symbolic links to the appropriate folder from %windir%\system32 and %windir%\SysWOW64. Thus allowing the WOW64 to take care of allocating the proper components based on the running application.
We are moving to an all-64-bit development environment. Unfortunately VS 2008 and, more importantly, its built-in web server, run in 32-bit mode. When debugging code that references 64-bit assemblies - Oracle.DataAccess, for example - we experience the dreaded System.BadImageFormatException.
Can anyone offer any strategies for debugging code with 64-bit dependencies in VS? I suppose we could use a 32-bit Oracle provider, but we would like to emulate the production environment as closely as possible.
I have a similar setup on 64 bit Vista where I have the web site deployed in IIS - this site has in been successfully run and debugged in both 32 and 64 bit.
The biggest problem I have found is working in a mixed environment where some members on the project team are still on 32 bit Windows (both XP and Vista).
This causes headaches with project references to Oracle.DataAccess which I have only managed to solve with bindingRedirect entries in the web.config file in order to point to the correct version of the assembly.
If you use IIS7 you can choose 32/64 bit mode. You will then have to have your projects kick up with IIS instead of cassini which takes a little bit of work, but I think it will solve the problem with Oracle at least. Honestly I don't know how that would all work when attaching at 32bit debugger to it.
We use VMware hosts to give each of our web site developers their own virtual web server. You can use full IIS (as #KevinWon suggested) and install a 64-bit version of the debugger on them. I don't know the specifics of what our guys do - I found this out over a coffee the other day.
Set up an local IIS on your computer and set it to run in 32bit mode
http://kb.parallels.com/en/2131
If you enable the Debuging mode you can work with it, just like you would with the integrated development server. But you don't have to mess with the 32/64bit assemblies