The first thing to do is to make sure that you are using 32 bit drivers if you have a 32 bit SQL Server and 64 bit drivers if you are using a 64 bit SQL Server. 64 bit SQL Servers can't use 32 bit ODBC (or OLEDB or anything else) drivers.
I have had the old ODBC drivers from Microsoft bring down server instances, so i avoid them.
On recent versions of SQL Server, 2005+, I've had the best success with the "ACE" drivers. These drivers replace the old "JET" drivers and were introduced with Office 2007. They are OLEDB based, but you wouldn't necessarily notice. The release for Office 2010 that comes in 32 bit and 64 bit versions. The redistributable ACE drivers are available for download on Microsoft's site.
With the new drivers, you don't need to create a system DSN like with the old ODBC drivers. You can just create the linked server and go. There should be plenty of examples of how to create linked servers using ACE drivers (both with TSQL and the SSMS GUI) on the internet.
You will want to be sure that the provider representing your drivers (look under the Linked servers folder for the Providers folder) is set to "Allow in process" and .
You may also find that accessing files on the network is harder than accessing the same file on a local disk. This is usually a problem with delegation and security. Getting that going can be a hassle, depending on your infrastructure.
(If you are interested, I did a few of blog entries "Legacy Connectivity in a 64 bit world" about three or four years ago, covering dbase/foxpro issues, 32/64 bit issues, plus db/2 and other stuff. There is probably more than there than you would want to read. This was back before the 64 bit ACE drivers were released, and things are better now.)