You Cannot Install A Driver On A 64-bit Version Of Windows When Which Of The Following Is True

[Jomega Gibson]

Youcannot install the 64-bit version of Microsoft Access DatabaseEngine 2016 because you currently have 32-bit Office productsinstalled. If you want to install 64-bit Microsoft Access DatabaseEngine 2016, you will first need to remove the 32-bit installationof Office products. After uninstalling the following product(s),rerun setup in order to install64-bit version of Microsoft Access Database Engine 2016:

Office 16 Click-to-Run Extensibility Component

You cannot install the 32-bit version of Microsoft Access DatabaseEngine 2016 because you currently have 64-bit Office productsinstalled. If you want to install 32-bit Microsoft Access DatabaseEngine 2016, you will first need to remove the 64-bit installationof Office products. After uninstalling the following product(s),rerun setup in order to install32-bit version of Microsoft Access Database Engine 2016:

Office 16 Click-to-Run Extensibility Component 64-bit Registration

com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "SQL Server returned an incomplete response. The connection has been closed. ClientConnectionId:98d0b6f4-f3ca-4683-939e-7c0a0fca5931".

The thing that makes my observations unique on this compared to others on the web is that although the problem happens ONLY on Java 8, I cannot get the problem to occur on one of the seemingly identical Linux servers that is running the same Java 8 JVM. Other folks have seen this problem on earlier versions of Java as well, but that has not been our experience.

I turned on SSL logging in the Java 8 JVM on a Linux instance which reproduces the problem. SSL logging is turned on using -Djavax.net.debug=ssl:handshake:verbose. This revealed some useful information.

Notice that TLSv1.2 is selected by the database server and used in this exchange. I've observed that, when connections fail from the problematic linux service, TLSv1.2 is ALWAYS the level which was selected. However, connections do not ALWAYS fail when TLSv1.2 is used. They only fail 5-10% of the time.

Now here is an exchange from a server that does NOT have the problem. Everything else is equal. I.e., connecting to the same database, same version of the JVM (Java 1.8.0_60), same JDBC driver, etc. Notice that, here, TLSv1 is selected by the database server instead of TLSv1.2 as in the faulty server's case.

This appears to have been fixed in version 4.2 of the MS SQL JDBC driver. I created a program where I connected to the server 1000 times, pausing 100ms between each attempt. With version 4.1 I was able to reproduce the problem every time, although it happened only sporadically. With version 4.2 I was unable to reproduce the problem.

I've also hit this issue on Windows Server 2012 R2, using JDBC driver 4.0 & 4.1 with Java 7. This Microsoft article pins the blame on DHE ciphersuites, and recommends disabling them or reducing their priority if you cannot upgrade to JDBC driver 4.2

If the server name in the connection string does not match the server name in the SQL Server SSL certificate, the following error will be issued: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "java.security.cert.CertificateException: Failed to validate the server name in a certificate during Secure Sockets Layer (SSL) initialization."

If there are none, or none look related, then it's probably something else. Check carefully the output of the command you were trying when you got the error message, as there may be other clues in the full output from that command, aside from the error message.

Occasionally aptitude will be too eager to remove or downgrade large numbers of packages to satisfy your request, in which case retrying with -f changes its priorities and helps it come up with solutions that involve removing/downgrading fewer packages even if it means not all changes you requested can go ahead:

Edit: this is an old answer, and since it was written a newer APT front end, simply titled apt, has become the preferred command line APT interface for end-users. It is still not the Swiss army knife that aptitude is, but it's a bit more human-oriented than apt-get. I haven't taken the time to investigate how it would help in the above scenario, but it's worth using.

A Unable to correct problems, you have held broken packages error message often occurs because you are trying to install or have installed a package that you're not supposed to install. These are some fast and easy ways to fix the you have held broken packages error.

Open your sources.list file in /etc/apt/sources.list and check that there aren't any software sources for a different Ubuntu release than the Ubuntu release that you are currently using. If you find any incorrect release lines in sources.list, open the sources.list file with sudoedit /etc/apt/sources.list, comment out the incorrect lines in sources.list by preceding them with a # character, save the sources.list file, and run sudo apt update to update the list of available software packages.

If you have manually downloaded a .deb file simulate installing it by running apt install --simulate ./downloaded-deb-file.deb. If downloaded-deb-file.deb cannot be installed because of unmet dependencies the results of apt install --simulate ./downloaded-deb-file.deb will list these unmet dependencies. Since the command is a simulation you don't need and shouldn't use sudo or run it as root. Note the version requirements of each unmet dependency and search the web for a .deb file(s) that meets these version requirements. If you have found a .deb file that meets its version requirements, download it and run apt install --simulate ./new-downloaded-deb-file.deb to check if the newly downloaded .deb file has any unmet dependencies of its own.

In Synaptic in the left pane click the Custom Filters button which is marked by the mouse cursor in the below screenshot. From the list in the top left corner select Broken. In the center pane will be listed any broken packages that still need to be repaired.

Select the broken packages one at a time. Select a broken package, and then open the terminal and run apt policy . The results of this command will tell you if that broken package was installed from the default Ubuntu repositories or from some other source. If the broken package was installed from some other source, maybe that package can be removed along with its software source and replaced by a different version of the same package from the default Ubuntu repositories. Usually this means fixing a broken package by downgrading that package to an older version.

If all of these methods don't work it is possible that the broken packages are caused by something that is embedded so deeply in the operating system that none of these methods have any effect on it. The first obvious place to look for this deeply embedded "something" is in the software sources in /etc/apt/sources.list. Check the sources.list file to see if it contains any non-standard lines that may be causing a broken packages error. A standard Ubuntu sources.list file looks like the sources.list files in this answer.

Here, you can see two versions for the package nginx is available. The version required by X is Z. According to the version table, version Z for the package Y is available. But apt always installs the latest version. So there are two ways to fix this:

Update: After thinking about it for a bit, I think the warnings I was getting about the packages that aren't ready to be installed yet, were being treated as errors, and breaking the && chain from continuing. Probably had I just chained the commands together with ; it would have worked.

I had the same problem reinstalling xsane after a failed ppa installation. As happened to yochannah (now called 'StackExchange What The Heck'), "no files listed in dpkg --get-selections grep hold, and no joy after sudo apt-get update".

Because of yochannah's answer, I had the feeling I must remove some previously installed packages. And it was so, I had to manually remove all related packages to sane, amongst others xsane-common and libsane, which was still installed as the ppa version.

aptitude package manager is a much more handy installer than apt-get. It also suggests resolving conflicting dependencies and broken packages. The following were the conflicts in my system. They may differ from yours but the high-level method to resolve them would be the same.

Aptitude gives sometimes provides a viable potential solution. Such as upgrading or downgrading other libraries to solve the conflict. In my case, there was no solution. Hence I need to further track down the dependencies.

Because I changed just a few minutes before the position:"For other packages, subscribe to:"I changed it from "all updates" to "only security patches/updates"- and when I changed it back to "all updates"- I could finally install everything.

If you are unable to install/remove any new packages using package managers, and seemingly there is no other option than to backup your data and do a clean install of the system, you may try this first:

(Instead of --force-all you may use one or combine more as described in dpkg --force-help . e.g. for rc you do not need to --force-... anything, for iHR it is enough to use --force-remove-reinstreq , etc.)

The first column in the output of sudo dpkg -l grep '^.[^i]' represents the status of a package and represented by two or three characters. e.g. ii, rc, iU, etc. Below is a list of the possible characters and their meaning:

To demonstrate a broken package, I downloaded a bunch of .deb packages required for npm package. I then removed two of the packages there and installed the rest in the directory with sudo dpkg -i * and hence a broken package dependency situation was created. Then I did as stated above.

3a8082e126