Access 2013 - Dbase (.dbf) Table Import option

Anonymous
2013-02-03T16:16:55+00:00

I need to be able to import read/write Dbase dbf tables - yes they are still around so why has the standard option that was in Access 2010 gone?

I have seen mention of ISAM, which is gobbledegook to me. So please a simple answer - what do I need to install or change and how do I do it?

Microsoft 365 and Office | Access | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments
Answer accepted by question author
ScottGem 68,840 Reputation points Volunteer Moderator
2016-09-08T09:08:22+00:00

Was this answer helpful?

60+ people found this answer helpful.
0 comments No comments

158 additional answers

Sort by: Newest
  1. Anonymous
    2016-08-03T22:21:59+00:00

    Yeah, Microsoft just **** fix it!!!!  I'm sitting here getting yelled at by a user because you all can't get your **** together. 

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2016-05-24T19:42:47+00:00

    Hindsight will get you every time.  I just wish Microsoft would respond directly regarding the issue.  Are they working on it?  Do they plan to??  Are they unconvinced???

    Was this answer helpful?

    0 comments No comments
  3. George Hepworth 23,120 Reputation points Volunteer Moderator
    2016-05-24T18:19:58+00:00

    Yes, Scott is right, and thanks for clarifying.

    What I meant was that the MS team had no direct evidence at their disposal about the penetration of .dbf files in the specific businesses disproportionately impacted. Should they have known about that? I can't say. Perhaps, in hindsight, one could think so, but then, hindsight is always clearer than foresight.

    Perhaps this is also a cautionary example of over-reliance on so-called "Big Data". If you base decisions on aggregations that fail to take account of the details, it's too easy to miss something important.

    Was this answer helpful?

    0 comments No comments
  4. ScottGem 68,840 Reputation points Volunteer Moderator
    2016-05-24T16:47:16+00:00

    I would not hold my breath waiting for an explanation. That's generally not how MS works. 

    1. What George meant by snuck up on the dev team, was that they were not aware of the the use in GIS systems or the requirements for dbf when the decision was made to deprecate dbf support. It only came to light afterwards. 
    2. The problem here is that something changed between 2010 and 2013 that would have required a major effort to retain dbf support. I don't know exactly what changed, I only know that there was a change with left the team with a decision about whether to continue supporting dbf or not. This change did not occur in Excel hence the continued support for dbfs in Excel. DBF support would not have been dropped otherwise. I do know that it was not a decision made lightly, but it was made based on telemetry showing the need for dbf support had waned greatly. Anything that is removed is removed because leaving it in would cause issues with other new features or formats. nothing is dropped because someone said, its not used anymore so we don't need it. 

    So now the team is faced with the decision of how to restore support without breaking something else. Otherwise I suspect it would have been restored by now.

    Was this answer helpful?

    0 comments No comments