We have an application that makes use of OLEDB and the Jet engine Microsoft.Jet.OLEDB.4.0. We are converting our application to also run in 64-bit mode. However, the database engine is no longer a standard part of 64-bit Windows. But Office 2010 64-bit does install a 64-bit access database engine (See http://www.microsoft.com/downloads/en/details.aspx?familyid=C06B8369-60DD-4B64-A44B-84B371EDE16D&displaylang=en) so you can use Microsoft.ACE.OLEDB.12.0.
So I am working on fixing issues so that our application runs in 64-bit mode as well. But the OLEDB code complains about the database engine not being registered. So I try to install the redistributable 64-bit engine on the above link. But it tells me I need to uninstall 32-bit Office 2007 first. No way am I going to do that, because I am sure some settings etc. will be lost.
So my questions are:
How is that the 32-bit database access components do not work in 64-bit mode, but you cant install the 64-bit one if the 32-bit is installed already? Does that make any sense to anyone at all?!
I realize Microsoft wants people to switch to SQL server Express, except it is too invasive, does install reliably even on clean new Windows 7 computers, and it is not simple to copy or move the data around between different machines. Is there a suitable alternative to Jet then? Something that is simple but works on 32 and 64 bit and ideally has OLEDB and ODBC support? SQLite looks promising maybe?
Just did a quick search and there doesn't seem to be alot of alternatives to Access without going to SQL server. I found This, http://www.vistadb.net/, which sounds cool but the developers license is pretty expensive.
As an alternative, you can still use Access without installing the 64 bit driver. This happened to me, had to read from Access but could not convert the app to 32 bit. My answer was to write a separate 'proxy' executable that would run in 32 bit. I'd start the app using the System.Diagnostics.Process object and communicate with it through redirected standard input and output, passing the connection string as a command line parameter. The DataTable class has built in ReadXML and WriteXML functions which makes passing the data like this easy.
Related
I start my second semester of university on the 6th of July and one of my subjects is Database Concepts.
For the subject, we must install two programs "Oracle SQL Developer" and 'Oracle Database Express Edition". There is a Mac version Oracle SQL Developer but only Windows or Linux for Oracle Database Express Edition. I tried to install the latter with Docker but keep running into issues. Mainly when I start it there are no logs and I always get this error:
"The Oracle Database is not configured. You must run '/etc/init.d/oracle-xe-18c configure' as the root user to configure the database.
The following output is now a tail of the alert.log:
tail: cannot open '/opt/oracle/diag/rdbms///trace/alert*.log' for reading: No such file or directory
tail: no files remaining"
I have followed this tutorial and done exactly what he does but at timestamp 11:47 you can see that he has log messages while I just have the error posted above.
https://www.youtube.com/watch?v=CbopSCwATIg
Hoping someone can help me with this, if I can't fix this then I will have to use my Windows partition which isn't very convenient. If there. is no solution to this can someone please recommend an alternative of Oracle Database Express Edition for Mac that is free?
Many thanks.
To run the Oracle Database in MacOS, you have different choices. The most easy ones are:
Oracle Cloud Free Tier
You can setup your free online Oracle Cloud Free Tier environment and configure your local SQL Developer installation to the Cloud environment. https://www.oracle.com/cloud/free/
For further information about the Cloud Free Tier environment, check the posts https://dgielis.blogspot.com/2019/09/best-and-cheapest-oracle-apex-hosting.html from Dimitri Gielis for detailed instructions on how to do that.
Note that this is the only option if you own an ARM64 (M1/M2) based Mac.
Vagrant/VM
For a local setup, this is the most easy way in my opinion, since I'm not an experienced user of Docker. Oracle has made Virtual Machines available for free, https://github.com/oracle/vagrant-projects
Use the OracleDatabase v18.4.0-XE or v19.3.0 image, if you need the database only.
Use the OracleAPEX (v18.4.0-XE) image, if you intend to use APEX as well.
Docker
If you are known to Docker or want to learn it, you can follow the link in #Bjarte Brandt comment https://github.com/bjarteb/oracle-apex-ords. The setup documentation in that link is quite comprehensive.
Update due to Apple's M1/M2 processor
Since Apple introduced new M1/M2 mac's based on the ARM cpu architecture, the only option left available for the moment is the Oracle Cloud Free Tier. Unfortunately, VirtualBox VM doesn’t support the ARM architecture yet and it doesn’t work with Rosetta..
(13/09/2022) Oracle SQL Developer 22.2.1 is now natively available for MacBook M1/M2 clients. Previous versions would need Rosetta to run. Unfortunately, no signs for VirtualBox supporting ARM yet..
If you own a MAC based on the 'old' Intel processor, you would still have the other two options as well.
I will update this answer when more options for M1/M2 mac's become available.
Does anyone knows how to install Teradata in Debian or CentOS?
I wanted to give Teradata a try but I can't really find a download installer and/or clear instructions anywhere to install it.
If Plan A doesn't work (it's not simple, or even possible to install it) I was wondering if any of the following alternatives would work (and are really useful for basic usage):
Plan B: I saw a downloadable VMWare image somewhere that I could try to use.
Plan C: I think I saw an AWS (Amazon Web Services) offer time ago.
If you had done it can you point me to the right path? Otherwise, if you have tried any of the alternatives, did it work well?
Note: This is not for a production installation, but more as a learning experience, and to study this database.
Teradata runs on Suse SLES 11 only. The easiest (and recommended) way to get it on any other OS is to use the virtual edition on VMWare (Player):
Teradata Express
You need to register to be able to download.
While deploying my .NET 3.5 Windows form to different environments we ran with lots of invalid provider issues.
It works on some and doesn't work on others.
Could someone please help me out, how do I determine which version of "Oralce.DataAccess.dll" to use i.e. 9 or 10 or 11 or 9.1.* or 10.1.* or 11.* or 12 etc.
Does it depend on server where I'm installing an application? OR
Does it depend on back end oracle database?
I second the notion of using the 100% managed provider. It eliminates the need to know details I'm about to discuss. The only issue here is I think you might need to upgrade to .net 4.0.
TLDR Version:
Use the 12c 100% managed provider instead.
The short answer is don't mix the provider (Oracle.DataAccess.dll) with a different version of the unmanaged client (at least not backwards).
Consider redesigning to include a service layer that eliminates the need to have the Oracle provider on the client in the first place.
Full version:
First, lets make sure we understand the components of the old unmnaged provider (not the new 12c 100% managed provider). It's made up of two pieces:
the managed .net component - Oracle.DataAccess.dll
the unmanaged (non-.net) client
Simply speaking, Oracle.DataAccess.dll is nearly just a wrapper, translating .net instructions into ORACLE-NET instructions for the unmanaged client.
That said, when you load Oracle.DataAccess there is a order in which it tries to locate the unmanaged client dlls that it needs. From the Oracle Documentation:
The Oracle.DataAccess.dll searches for dependent unmanaged DLLs (such
as Oracle Client) based on the following order:
1.Directory of the application or executable.
2.DllPath setting specified by application config or web.config.
3.DllPath setting specified by machine.config.
4.DllPath setting specified by the Windows Registry.
HKEY_LOCAL_MACHINE\Software\Oracle\ODP.NET\version\DllPath
5.Directories specified by the Windows PATH environment variable.
This comes into play if you have more than one client installed on the machine so this could be part of your issue. If so, the simple thing to do is use the dllPath configuration variable in your config:
<configuration>
<oracle.dataaccess.client>
<add key="DllPath" value="c:\oracle\product\1.1.0-xcopy-dep\BIN"/>
</oracle.dataaccess.client>
</configuration>
Now, to answer your question directly - I don't believe Oracle supports mismatching Oracle.DataAccess.dll with it's client (at least not backwards). Your best bet is either to install ODP.net with your app install - the xcopy version is the smallest and contains the "instant client" Or, you should be thinking about minimum system requirements - ie. The system must have at least version X of odp.net installed. You could then compile against that minimum dll and rely on publisher policy redirection when a target system has a NEWER version of the client.
Of course this also prompts me to ask about architecture. Do you plan on prompting the user for their Oracle account? If not, you have to be careful on how you protect the shared service account your application will use. You may be better off making calls to a webservice that makes the oracle calls on the clients behalf - giving you another security layer and simplifying your client deployment.
Most version of ODP.net are backwards compatible with the database server - you can certainly use the 11g provider with a 10g database.
First of all clarification:
You have an Oracle Database Server (you called it "back end oracle database") and an Oracle Client (no matter if this is installed on an application server, from Oracle point of view, it is the client)
The version of ODP.NET (Oracle Data Provider for .NET, i.e. the Oracle.DataAccess.dll and some more files) are defined by the Oracle Client. You can use almost every ODP.NET version to connect to every Oracle database version - more or less.
The error message "The provider is not compatible with the version of Oracle client" could also mean there is no ODP.NET provider installed at all. In this case the error message is indeed a bit misleading. So, first check if ODP.NET is installed at all, it is not included in standard Oracle Instant Client installation.
When I check all available downloads from Oracle you have ODP.NET version
9.something
10.something
1.x
2.0
4.0
9.? and 10.? refers to version of Oracle, 1.x, 2.0 and 4.0 refers to version of Microsoft .NET Framwork (strange numbering, but that's how it is). Version 9.? and 10.? are very old, I don't think it makes any sense to use them. 1.x was supported until Oracle client version 11.1.
If your Oracle client is 11.2 or higher you are forced to include ODP.NET version 2.0 or 4.0.
If your Oracle client is between 10.2 and 11.1 you can use eiter ODP.NET version 1.x or 2.0
If your Oracle client is older than 10.2, I don't know how it works - it's outdated anyway.
Version 1.x and 2.0 are not compatible to each other, i.e. perhpaps you have to provide two different setup files of your application to your customer and the customer has to select the correct one depending on his local oracle client installation.
I don't know the situation for 2.0 vs. 4.0, I never used 4.0 so far.
It is not required to put a local copy of Oralce.DataAccess.dll into your application directory. It will be taken from GAC (Global Assembly Cache) where it is installed.
In your developing you only have to take care only these mayor version, for example 2.0.
Then your loal GAC knows due to policy files which exact version is loaded, e.g. 2.0.10.2.0.2.20 or 2.0.11.1.0.6.20 or 2.0.11.1.0.7.20 or 2.0.11.2.0.1.2 or whatever.
On top of this all you have to know whether your Oracle client is 32bit or 64bit and include ODP.NET accordingly.
Here you can get more information: Oracle Data Provider for .NET FAQ
if you have client or oracle instance installed in your system. check the folder name
ORACLE_HOME\product\11.2.0\dbhome_1\ODP.NET\bin\2.x
here you will find the file - Oracle.DataAccess.dll
just include in your reference.
In fact I believe there is no right answer.
It all depends on the processor architecture (so bits) the application runs with, the version of OCI client you use, etcetera.
I found it most useful to wrap the Oracle interaction in one class, using Reflection to find the available version to use.
Regarding the version number: the version of the ODP.net assemblies must match those of the OCI client installation. It is a bad idea to mix the 12.* OCI client with the 10.* ODP.net assemblies.
Maybe this article is also useful to you.
If your Oracle server is version 10.2 or higher, you could consider simply using the managed ODP.NET version which came available with Oracle 12.
Apparently it's one dependency, under 10 MB. It should make deploying your application to different systems a lot easier compared to the ODP.NET versions that depends on Oracle (instant) Client. It should also avoid you having to care about any installed Oracle Client.
However, they do mention it works on "the latest version of the .NET Framework 4.5.1", so from what I understand you need to upgrade your application to 4.5.1, but maybe that is only if you want to use the certain features (like the Entity Framework support).
http://www.oracle.com/technetwork/topics/dotnet/index-085163.html
Sometimes you get the Could not load file or assembly 'Oracle.DataAccess' or one of its dependencies. whereas you have the right dll and the problem is somewhere else.
It happen to me (and this topic helped me a lot to figure it out) and it was the configuration of my application pool in IIS who wouldn't allow 32 bit applications (advanced settings).
I am trying to create a test environment (for my own practice and research) on how best to virtualize an Oracle DB using windows (Unix/Linux comes later...much later).
Here's the idea:
Use Virtual PC (for win7) and install Server 2008 x64 with Hyper V. Then, create a virtual guest (XP or something) that connects to it. Install an Oracle instance (11gR2) on the server and then go to work to connect to the DB instance from furhter vitualized XP O/S.
After that, create a Data Warehouse (DWH) on another virtualized O/S using the server as the data source.
Basically:
Server(DB) to DWH
Server(DB) to client computer
client computer (DWH Manager) to DWH
I would just like to know if this seems a valid way to build a testing environment or is this not such a good idea and there are better ways to do this?
Additionally, I am largely unfamiliar with Hyper-V Server 2008 and virtualization (even after reading the docs on it - someone with practical experience would be helpful in suggestions)
I have Win 7 x64 installed on my machine and have been running an 11gR2 DB for the past 6 months as part of a personal project (and continued education)
I appreciate any and all suggestions, thanks
What are your concerns? The main disadvantage will be performance, but that's usually not that important in a development environment.
I am developing Delphi 7 application, which is operating with Access Database (MDB format). It works fine on my PC, and some other PCs as well. But on some machines application gives error when trying to access database sometimes, saying something like "Unkown database format (mdb)". Additionally I noticed one thing: When you open that database in Ms Access using Office, it is opened in "read-only" mode for some reason. Can anybody help? What could be the reason for the problem?
It's been a long time since I have programed in Delphi, but I remember I had issues with different versions of MDAC installed. Compare the versions between the pc's that work and those that don't.
I think your most likely problem is to do with MDAC, use the registry to check what version is on each machine and see if there is a differnce between the ones that work and the ones that dont.
I used to get that error message if the database file (the mdb file) was actually set to read-only (for example, if it had been copied off a CD). Check the file properties in Windows Explorer and ensure the file isn't read-only.
Also, have you tried doing a Compact & Repair within Access, as Access databases regularly corrupt and this option can often help cause all manner of problems.
What version of Access is the MDB formatted for? Are you using DAO or ADO to access the databases. Is the MDB in 2003 or 2007? I suspect it's in A2007 format and the machines you are having troubles with have A2003 installed or no version of Access at all. Whereas the machines that work do have A2007 installed on them. But that's just a guess.
You also need to track down the read only problem too.
You say: "It works fine on my PC, and some other PCs as well."
Then it sounds like there might not be anything wrong with your program. What it could be is that the PCs it won't work on all the time do not have Microsoft Office or at least Microsoft Access installed. They need to have Access installed for ADO to work.
A "sometimes" problem on a machine is difficult to diagnose without further clues.
I'm afraid I don't know what the "Read-only" problem might be.