Drivers for dBase (or Access or Excel) are not installed as part of the SQL Server install. It is likely that VS 2010 installed on your workstation is connecting through the old Jet drivers, which are installed on developer's machines. The problem with Jet is that it was never ported to 64 bit. I don't think that the old Visual FoxPro drivers were ported to 64 bit, either.
Microsoft replaced Jet with "ACE", which is available in 32 and 64 bit packages. ACE drivers were first released with Office 2007 and supplant the older (and probably deprecated) Jet drivers.
You can download the ACE 2010 drivers here. Since you are using a 64 bit server, you want the 64 bit drivers for linked servers. If you plan on running 32 bit packages on the server, you would need to install the 32 bit ACE as well.
You might be able to find a similar package for 2013 by now. I have not used these more recent drivers, so I don't know if the the older formats (like dBase, Fox, etc) are still supported.
After you install the drivers, they generally need additional configuration inside of SQL Server. IIRC, if you see errors that seem to be security-related, you need this additional configuration. In short:
EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0', N'AllowInProcess', 1
GO
EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0', N'DynamicParameters', 1
GO
Note that running drivers in-process could affect the stability of the instance, if those drivers are buggy.
After the drivers are installed, you will need to configure a valid linked server.
You also need to be sure that SQL Server has permission to read (and maybe write) the files.
This:
SET SHOWPLAN_XML ON;
GO
SELECT * FROM sys.objects;
GO
Is equivalent to pressing Display Estimated Execution Plan on the toolbar (or hitting Ctrl + L). You'll notice that no rows are returned from the query, like there is when you use Include Actual Execution Plan (Ctrl + M).
The spill warning is only a runtime warning. There is no way that SQL Server can know, when displaying the estimated plan, that a spill will happen at runtime. This is because a spill is caused by factors that might only be present during certain invocations of the query (for example, when there is memory pressure). The estimated plan knows roughly how much memory it's going to ask for, but it can't know until execution that it isn't going to get it.
As an aside, may I recommend* our free tool, SQL Sentry Plan Explorer? I think it provides much more obvious information than Management Studio. I recently wrote a lengthy blog post that can act as a tutorial, and Jonathan Kehayias has a great PluralSight course on it as well.
* Disclaimer: I work for SQL Sentry.
Best Answer
Run
SELECT @@VERSION;in a query window, with results to text. You will see something like this (minor details will vary) in the Messages pane:Help > About in Management Studio is just about the client tools, so may not even reflect the same version as the server, never mind that Management Studio no longer has any edition differentiations.