Access 2013 - Dbase (.dbf) Table Import option

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").

1. 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.

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.

Just to be clear I was not referring to you when I referred to unfounded statements. In fact the only reason I responded to your post was because of the specific question you asked.

Scott,

Thanks for the quick reply.  My interactions with MS goes over many years, over many issues, and with various levels of the MS organization.  For myself, I don't believe I've made any statements without foundation.  You may have been referencing previous posts.  I understand your position as an uncompensated, dedicated MS helper and the many unsubstantiated posts (or rants) you have to deal with. 

Yes, I've participated in development team blogs and have had various levels of success.  But, for me, at some point, the ROI does not seem to be justified.  However, even if the dis-satisfied group is less than 5% on some issue, why make even that small number mad.  I'll take two examples; 1) removing the dbf function from Access, and 2) removing Picture Manager from Office.  Obviously, the code is written and works.  And Excel still works with dbf files.  What business or marketing advantage is there in removing this functionality from Office?  Yes, customers still purchase and for the most part are satisfied.  But there is no doubt that there are competitors successfully nibbling. It would be an interesting management study to see the facts on how those decisions were made.  Probably not by people who ever used either function.

Cheers,

J Austin