Such an approach is very complicated, and is unlikely to ever result in all your packages being the amd64 version instead of the i386 version. Only packages that actually receive upgrades will likely be changed in architecture, and probably only if no other packages not being upgraded rely on their being of the i386 architecture. Since some packages will not receive any updates throughout the entire support cycle of your Ubuntu release, you will likely never have a fully amd64 system using such a technique. Furthermore, there is certainly no official support for such an approach.
You would be well-advised to instead replace your existing Ubuntu system with a new, 64-bit installation.
However, if you do wish to attempt this technique, you will have to manually download the .deb files for dpkg and apt. You can find them at the dpkg in Ubuntu and apt in Ubuntu pages on Launchpad--expand the latest version under "The Oneiric Ocelot" that is marked as release, security, and/or updates (but you probably don't want a version marked only proposed and/or backports, if there ever is one). Then download the .deb files marked amd64. Specifically, the files you'll want are: this one for dpkg (and the others listed, too, if you have those packages installed) and this and this and this and this and this for apt.
Before you do anything with these files, you should make sure to back up all important documents in your installed Ubuntu system and any other important files (e.g., music, ebooks, videos), because it is rather likely that attempting this technique will backfire badly and leave your Ubuntu system completely unusable.
You can install all these packages by putting them in a folder that contains nothing else (suppose the folder is called debs and is inside your Downloads directory), and then running this command:
sudo dpkg -Ri ~/Downloads/debs
Of course, once you've installed them, they won't actually run, because their executables are 64-bit and your 32-bit Ubuntu system is running a 32-bit kernel (which will only run 32-bit executables). In fact, they might not even finish installing, as they might have post-install scripts that invoke their unrunnable 64-bit executables.
There are various ways of attempting to install a 64-bit kernel onto a 32-bit system, but they are all extremely complicated, so instead I recommend that you boot from a 64-bit Oneiric live CD (which itself runs a 64-bit kernel), chroot into the installed Ubuntu system, and use the recently installed 64-bit apt and dpkg to install a 64-bit kernel.
Here are specific instructions for doing that...but please do not take this to mean that I'm saying it will work. I have not attempted this. (I have chrooted into installed Ubuntu systems from live CD's and performed package management and other operations, but I have not attempted the cross-architecture operations suggested here.)
In your installed Ubuntu system, open a Terminal window (Ctrl+Alt+T) and run mount | grep ' on / ' (by pasting it into the Terminal and pressing enter). You should see something like /dev/sda2 on / type ext4 (rw,errors=remount-ro,commit=0). The part you're interested is the device name before on (in this example, it's /dev/sda2). Remember that, or write it down.
Step 1 gave you the device name of the / partition. If you have a separate /boot partition, then you'll need to know the device name for that as well. So in that case, run mount | grep ' on /boot '. You'll see something like /dev/sda1 on /boot type ext2 (rw). Remember or write this down as well.
Boot from an Oneiric amd64 (i.e., 64-bit) live CD and select "Try Ubuntu" rather than "Install Ubuntu".
Go into a web browser and make sure that Internet connectivity is fully functional. If it isn't, set it up.
Open a Terminal window and run sudo mount /dev/sda2 /mnt (replace /dev/sda2 with the device name you got in step 1, if different).
If your installed system has a separate /boot partition, run sudo mount /dev/sda1 /mnt/boot (replace /dev/sda1 with the device name you got in step 2, if different).
Now, run these commands to chroot into your installed system:
sudo mount --bind /dev /mnt/dev
sudo chroot /mnt
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devpts none /dev/pts
Run ping -c 4 launchpad.net to see if Internet connectivity works fully from within the chroot. You're hoping for something like this:
PING launchpad.net (91.189.89.223) 56(84) bytes of data.
64 bytes from launchpad-net.banana.canonical.com (91.189.89.223): icmp_req=1 ttl=41 time=141 ms
64 bytes from launchpad-net.banana.canonical.com (91.189.89.223): icmp_req=2 ttl=41 time=143 ms
64 bytes from launchpad-net.banana.canonical.com (91.189.89.223): icmp_req=3 ttl=41 time=142 ms
64 bytes from launchpad-net.banana.canonical.com (91.189.89.223): icmp_req=4 ttl=41 time=140 ms
--- launchpad.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
If, instead, you were unable to transmit or receive packets, then you'll have to set up Internet connectivity in the chroot. To do that, run these commands (to leave the chroot, copy the relevant configuration files from the live CD system into the chroot, and re-enter the chroot):
sudo cp /mnt/etc/resolv.conf /mnt/etc/resolv.conf.old
sudo cp /mnt/etc/hosts /mnt/etc/hosts.old
sudo cp /etc/resolv.conf /mnt/etc/resolv.conf
sudo cp /etc/hosts /mnt/etc/hosts
While generally you should stop this process if there is an error, don't worry if the first and/or second of those four commands fail, provided that the specific way in which it fails is by telling you that /mnt/etc/resolv.conf (or /mnt/etc/hosts) does not exist.
The chroot back in and try again:
sudo chroot /mnt
ping -c 4 launchpad.net
Run these commands to make your chrooted environment fully ready to use:
export HOME=/root
export LC_ALL=C
If you haven't installed the .deb files for the 64-bit versions of dpkg and apt, so do now. If you did install them but there were configuration errors, run dpkg --configure -a to fix them. (Hopefully that will work...it might be better to wait to attempt to install them until you're in the live CD environment, in case installing the 64-bit dpkg while booted into the installed system leaves dpkg in an unusable state.)
With the 64-bit versions of dpkg and apt installed, assuming that they will automatically install 64-bit packages, you can now remove all your 32-bit kernels and install a 64-bit kernel. To remove your 32-bit kernels, run dpkg -l | grep linux-. This lists installed packages that start with linux-. You're more specifically interested in packages that start like linux-generic, linux-image, linux-server, and/or linux-headers. Remove these files with apt-get purge ... where ... is replaced with a space-separated list of the packages you're removing.
Now reinstall the packages you removed. (Actually, for packages that contain version numbers in the package name, like for example linux-image-3.0.0-13-generic, you only need to install the latest versioned package names.) Do this by running apt-get install ... where ... is replaced with a space-separated list of the packages you're installing.
Update the boot loader configuration, unmount some devices, and leave the chroot:
update-grub
umount /proc || umount -lf /proc
umount /sys
umount /dev/pts
exit
sudo umount mnt/dev
If you ran sudo cp /mnt/etc/resolv.conf /mnt/etc/resolv.conf.old and it did not fail, then now run sudo cp /mnt/etc/resolv.conf.old /mnt/etc/resolv.conf.
If you ran sudo cp /mnt/etc/hosts /mnt/etc/hosts.old and it did not fail, then now run sudo cp /mnt/etc/hosts.old /mnt/etc/hosts.
If your installed system has a separate /boot partition, unmount that: sudo umount /mnt/boot
Unmount your installed system's / partition: sudo umount /mnt
Leave the Terminal window (run exit), then reboot (or shut down) the live CD system and boot into the installed system.
See if the system is usable and running a 64-bit kernel (uname -m should say the architecture is x86_64).
There might well be additional packages you need to install, such as ia32_libs and/or the 64-bit version of libc6, for this to work. For some of them, you might be informed you need them when attempting to install the 64-bit version of dpkg and/or apt. For others, you might not be informed.
(The above instructions for chrooting and operating in the chrooted environment are based in significant part on this related but different procedure and also on some Launchpad Answers posts of mine, especially #6 here and #6 here. And special thanks to Caesium for pointing out that the 64-bit dpkg and apt executables won't run on a system running a 32-bit kernel.)
Best Answer
I was using a newer version of libodbc1 by Microsoft which was not compatible with libodbc1:i386. I disabled Microsoft packages URL, and downgraded libodbc1 to version 2.3.6-0.1build1, and libodbc1:i386 installed just fine. Everything seems to be working now. I just hope Microsoft products don't break in the future.