A family of Microsoft relational database management systems designed for ease of use.
Access 2013 - Dbase (.dbf) Table Import option
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.
158 additional answers
Sort by: Most helpful
-
George Hepworth 23,120 Reputation points Volunteer Moderator2016-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.
-
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.
- 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.
- 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.
-
Anonymous
2016-05-24T15:45:07+00:00 GroverParkGeorge, I really appreciate your opinion, the concise summary, and your assurances that the Access Team has repeatedly heard this explanation. I'd still REALLY like to hear a valid explanation or something (anything) from the Access Team or Microsoft...
A few things I'd like to add/clarify (using the same disclaimer that this is "just my opinion").
- This should not have "snuck up" on the Access team in the first place...there have been pleas from those of us that need to work with dbf (in Access) since 2013 rolled out. The reason the complaints have gotten louder is (IMO) directly related to the hardware/software upgrade schedules of enterprise-level users. As more users are being switched from the 2010 platform to the 2013+ platforms this is only going to get louder. Moreover, this issue causes me great angst when I consider the new subscription-based model of Microsoft Office. Now it's conceivable that a client will automatically receive some new version of Office with a key component suddenly missing and years of development work will need to be redone.
2) I'll admit, the number of "GIS/Access Developers" is very small and therefore likely not represented well (if at all) in any MVP/Access Team discussions. So, I'd really like to thank the MVP members who made sure the Access Team heard our voices. That being said, GIS is a 270+ BILLION dollar industry which largely relies on shapefiles (and the dbf format). Yes...there is a slow migration away from the shapefile (largely at the enterprise-level), BUT it still remains the defacto format for sharing GIS data across software platforms and for download. DBF won't be "dead" to GIS until the day you can no longer download shapefiles or work with them in GIS software.
3) I never use the {Scroll Lock} key on my keyboard...can we eliminate that too? That may be a facetious notion, but just because 'nobody' uses something, doesn't mean it's dead... especially if you do not consult the folks who rely on it. By that same logic, think about how much smaller the office object models would be if we just eliminated everything that 'nobody' uses. One quick Google (or Bing) search clearly demonstrates that dbf is very much alive. Which leads me to believe there must be an ulterior motive for its deprecation. If there is logic in that motive, I'd REALLY like to hear it.
-
George Hepworth 23,120 Reputation points Volunteer Moderator2016-05-22T23:46:23+00:00 The following is my personal opinion about this problem. It doesn't represent any point of view except my own, and a couple of friends and a colleague in the mailing list business with whom I discussed it.
The problem, as I see it, is not that the .dbf format is used by a very small percentage of people. That's true, but not all that important, IMO.
And the problem is not that it primarily impacts developers; it doesn't. It primarily impacts NON-developers That's also true, and that is pretty important, IMO.
It's true that the absolute number of users who DEPEND on the .dbf file format has been small. It's also true, though, the impact falls on users who are not otherwise database developers.
There are two industries which are disproportionately impacted. One is the mailing list industry. The other is people who work with GIS systems. My understanding is that neither of these groups are heavily represented among "Access developers" and that's a big part of the reason this is such a difficult subject.
As developers we're highly motivated to solve data problems in creative ways. If we can't use one tool, we find another. And that, I think, is one important reason why this issue snuck up on the Access team. They didn't realize, I don't think, that although the absolute number of people using the .dbf format was quite small indeed, it comprised a very high percentage of those who work with mailing lists and GIS applications. Again, we are talking about small numbers but large percentage of those groups of users. And they depend on the .dbf format.
There is one other important characteristic of both groups. Neither is what we would think of as a "developer community". And neither can be expected to collectively shrug and say, "oh well." To a large part their businesses are BUILT on that format and to a large part, they don't care about Access except that it something they use in their "real" jobs.
I can assure you that the Access Team has heard this explanation from the Access MVP group, and that they have heard it more than once. I can't say what the ultimate outcome will be. I am hopeful for a good outcome, but I can't really say for sure. And by good outcome, I mean a way to move forward with Access and .dbf files.