Product Team Status Update

Comments

# David Salaguinto said on November 27, 2007 4:17 PM:

Thanks for the compliment, Zac. Access is one of my favorite apps, and I'm really looking forward to 14.    -ds

# Tim said on November 27, 2007 6:55 PM:

Zac, in previous blog, Ryan talks about using Access as Admin tool for web apps. Could we use Access database to manage some of adminstration features of Sharepoint Server? I found it is not easy to work on Sharepint Central Administration Pages.

# Zac Woodall said on November 27, 2007 11:36 PM:

Hmm, that's a super interesting suggestion Tim.  With 2007 and SharePoint v.3 the answer is really no.  Much of that config info can only safely be accessed and edited using the SharePoint UI.  While it is true that under the covers everything is kept in SQL tables, the way information is stored is pretty complex, and edits made by hand to the SQL tables could easily break the system.

# Alek said on November 28, 2007 1:43 AM:

Dear Zac, I'm happy to read about new releases of my favorite product but please, please, tell us something about 2007 runtime without .adp reports bug.

# Vladimir Cvajniga said on November 28, 2007 4:51 AM:

Pls, don't forget the PDW. I always have problems installing Access applications on computers with different version of Access. I distribute A97 applications and at the moment I'm trying to create a setup for A2002. Never ending problems... pls, look around it. I'd appreciate a professional solution like Sagekey - rumours say Sagekey has no problems with installing any Access application on any system. Can Microsoft create a professional solution, pls?

# Gilad said on November 28, 2007 4:13 PM:

Access is part of my life. I think it is a great product, and therefore I care about how it develops.

It is for this reason that I want to ask the following question, with the hope that it will make some sort of minimal contribution to the direction of its development.

There are probably millions of shareware applications that have been developed over the years, for end users to download and install on their own initiative. It is my assumption that only a small insignificant fraction of these were created with Access, in spite of the fact that, compared to other platforms, it is probably easier, faster and more effective to write many of them in Access,. I think this should be some sort of a gage to evaluate Access, or at least some of its functionality and usability. I wonder if you agree with my assumption about these statistics, and if so do you have any explanations to this phenomena. I think that if it is true, it is probably mostly due to deployment issues. Things like the lack in stability of the product, lack of completed functionality, lack in a reasonable Package and Deploy utility, changes between versions and backwards compatibility. The free runtime is a step in the right direction, but it is still difficult to be sure that an application will work properly on different machines with different versions of Office. There are probably a multitude of other issues that you can also describe here as causes. Version and service pack reshuffling complexities, Dependencies, etc.

Maybe one of the things that may make some contribution to this issue is to include some of the runtime files with Windows. Since Windows is updated automatically this can help prepare end users to be able to run an Access application without requiring special extra downloads from them. Is this a crazy idea?

Is the shareware market not one that the Access team is interested in? Is it the team’s recommendation not to use Access for such purposes? I hope not. Will the next version be able to ease the deployment issues?

Thanks

Gilad

# Zac Woodall said on November 28, 2007 6:43 PM:

Re: Alek - YES!!  We have something on the way to address the 2007 Runtime ADP Reports issue along with a number of other Runtime specific probems.  Stay tuned!

Re: Vladimir - If you've got specific bugs on deploying mulitple versions of Access SxS, we'd love to see them!  We strive to make this work.  On the subject of the Package Wizard, this is a quick, lightweight, free solution that should meet rudimentary app deployment needs.  If you have more complex deployment requirements, you might be better off purchasing a full-featured deployment solution like SageKey.  

Re: Gilad - Great thoughts, thanks for sharing these!  Some of what you've said is right on, but I think I'd tend to disagree on some of your assumptions here.  Access is a tremendously popular platform for building simple data-bound solutions that solve a specific business need.  In a recent developer survey conducted by Microsoft which spans all software technology on every platform, there were as many people who claim to develop applications using Access as there are all other programming languages/platforms combined (note: each developer may list multiple platforms that they build for).

That said, I think you've also got a valid point about the shareware, general software space.  Access solutions are usually very targeted (e.g. I need to keep track of my budget for marketing projects for the next fiscal quarter, or I want to arrange for political donations for the upcomming campaign, or I want to track my personal DVD collection).  They are often completely customized to the need of the specific user building the app.  I might want my tool list report to be a different color, or have different fields, or a different sort from you.  

So yes, I wouldn't consider Access a general software development platform in the compter science sense.  A better way to think about it is as a tool for quickly addressing customized business data tracking needs.

# Guest said on November 28, 2007 10:25 PM:

Hi folks,

I have some questions. We use Access 12 now.  What is Access 14??? And where is the Access 13? :D

Anyway I've opened a thread in the following link.

And I've mentioned about a bug. And I sent a feedback a few days ago. Will you consider this issue for next release?

http://www.access-programmers.co.uk/forums/showthread.php?t=138920

# Gilad said on November 29, 2007 12:35 AM:

Thanks Zac for your response. I appreciate it very much.

I am disappointed by your response of course. I developed a couple of applications that I think can make a real difference for the businesses that may choose to use them, and basically what you are saying to me is to drop them down the toilet. I can not at this stage learn and profess in a different platform in order to transform them into. So I will try to do what I can to deploy them using Access and hope for the best.

From your reply I understand that the Access team is targeting the end user market and not the developers who develop applications for the end user market. And yet, on the other hand, you cited a survey that was answered by developers. Developers stated that they are acquainted with Access. Did the end users that you are targeting also do so? I hardly think so because Access can be very complicated to master and end users will require a lot of investment of time and effort in order to really begin to make good use of Access and its most basic features. It is still easier then C++ but that doesn’t mean you can build an effective Access application without some know-how.

What I hear you saying is this: We are making a really neat application-builder for end users, most of which will not be able to take best advantage of it because it is complex. So most of them will probably opt for Excel, which is easier to learn and implement and can be useful for simple data collection without being relational.

On the other hand, we are not targeting the developers of shareware applications, which all said they are proficient with Access and find it relatively simple and useful.

This doesn’t make enough sense to me. Sorry.

I understand making $$ comes from the end users, but only if they know what they are doing. I hope developers selling applications also constitute a market with $$ for Microsoft.

Thanks again for reading.

Gilad

# Zac Woodall said on November 29, 2007 1:36 AM:

This is a great conversation to have, Gilad.  

Maybe what I described above wasn't totally clear.  I think there is a really broad space that is somewhere between what I would consider an End User (someone who can send email, read web pages, track photos, create word docs, etc...) and someone I would consider a professional software engineer (who I would consider to be building and maintaining long term high-cost software projects; these folks usually have a BS in Computer Science or equivalent).  Access fits somewhere in there.

I totally agree with you that people who are capable of creating an Access database from scratch that incorporates VBA code to perform complex tasks need training.  In fact, I'd go even farther to say that it already takes a really savvy computer user to be able to create table schema and queries in a meaningful way.  I'd also say that developers with formal computer science training commonly yearn for more power and flexibility than is provided by Visual Basic, although the really savvy folks are great at using the right tool for the right job, and recognize that in some cases this will be Access + VB.  

Here's an interesting observation I've made.  Universities typicially offer two general branches of computer technology degree programs.  There is the Computer Science/Engineering school, and there is the Information Technology/Business school.  While the CS cirricula tend to focus on C/C++/C#/Java, it is very common for the IS classes to have courses which teach Access, or something like it.  It is interesting to consider why this is the case.  I like to think it is because Access is a tool focused on meeting business needs, which lines up perfectly with the goals for IS/IT.  By comparison, CS programs tend to be more theoretical in nature, exploring the larger world of what it is possible to coerce a computer into doing.  

Access is a part of Office, and Office is about addressing the needs of business.  Access has really always been all about data, and I think you can count on us to continue to make investments where we think those things make it easier for businesses to achieve their data tracking goals.  

So, I do not mean to suggest that you can't build a professoinal software product on Access.  Quite the contrary, I know many customers who are doing this very successfully.  Apps can usually be built using Access in a fraction of the time that it takes to build the same thing using C, C++, or even .Net.  The reason is because Access focuses on making it easier for people to do those things.  In the end of the day, that focus sometimes means that we lose some of the flexibility of the more generic programming platforms.    

# Vladimir Cvajniga said on November 29, 2007 9:52 AM:

Zak: Nor A97 neither A2002 has free deployment wizard. I've spent a fortune on A97 ODE & A2002 Developer Edition. IMHO, packaging wizard is not free... 'till A2007.

I'll post installation issues as soon as we go to beta testing of our new app.

P.S. I have no response from Dany Hoter yet, see "A chance to influence the direction of Access" at http://blogs.msdn.com/access/archive/2007/10/11/a-chance-to-influence-the-direction-of-access.aspx. I've e-mailed him Oct 18th 2007.

# Vladimir Cvajniga said on November 29, 2007 9:55 AM:

Guest: TYVM for the link! :-)

# Zac Woodall said on November 29, 2007 12:02 PM:

Vladimir: I understand now.  You've got a great point about the 97 & 2002 products.  Unfortunately there isn't much we can do about old versions.  The best opportunity we have is to try and influence the direction of future products.  I look forward to getting your detailed feedback so we can use it to improve the 2007 and 14 runtimes!

Yes, I know that Dany has recieved your feedback, and he is incorporating it along with the rest of the feedback we got into an overarching "this is what developers are building with Access" document that we'll be using to guide whatever decisions remain in 14, and the direction for 15 and future versions as well.  I think you may not be the the only one who hasn't heard back from Dany.  I know he got a -lot- of responses.  I just want to assure you that even if you haven't heard back from him directly, we have your feedback and we're using it to help guide our process for making design decisions.

# Gianni Zanetti said on November 29, 2007 4:05 PM:

Hi Zac,

Question on the A2007 Runtime Version and synchronizing to SharePoint. I noted well that Runtime is not supporting this synchronizing. I have shipped now my version to the client and require him now to be constantly online and skip the sync option. Yet I judge it as a key benefit if Runtime would support SharePoint Sync. Clients want to have at least a copy of "their data" locally, not only on a remote SharePoint. In a B2B environment, e.g. during tenders or other extranet-level workflows scenarios, it would be a killer app having a a easily deployable frontend to SharePoint with off-line updates. Will SharePoint Sync be reconsidered to be included in the Runtime version? What alternatives, if not?

# Zac Woodall said on November 29, 2007 6:41 PM:

Hello Gianni!  For Access 2007 we're unlikely to turn on new features (like sync) for the Runtime.  This is still super valuable feedback though, and it is definitely something we will take to heart for 14.  

# Frederick Grose said on November 29, 2007 7:56 PM:

In the Gilad-Zac discussion, Zac observes,

"Apps can usually be built using Access in a fraction of the time... The reason is because Access focuses on making it easier for people to do those things.  In the end of the day, that focus sometimes means that we lose some of the flexibility of the more generic programming platforms."

I would like to observe that there are so many significant programming activities that become MORE flexible, in a practical sense, with Access.  My favorite example is SQL query building.  Access had the first practical and accessible graphical query designer.  With it, as I look back at the complexity and utility of data processing and display that we were able to achieve, I am astounded.  I remember queries that were quite effortlessly built that pressed the query string limit in raw SQL and were frightfully unreadable in text.  The professionals using the more generic platforms would never have even conceived of the possibility of using a query to do the task and would have gone blind trying to.

What I noticed was that professionals were limited by the difficulty of using their tools.  Once there was a sharp tool that is easy to use, the scope of problems that can be solved is expanded by the ingenuity of those fortunate enough to have found, developed, or extended the tool.  That's how I've looked at Access, and its what I hear from Gilad.

It is true that generic programming can theoretically do more (and are essential to tool making), but in practice, sharper and easier tools often achieve more results for more people.  It's the classic software engineering problem that Charles Simonyi address with Intentional Programming, http://www.intentsoft.com/.  And Microsoft Access holds an honorable place in the evolution of software.

I believe that by following these principles, the Access development team can restore the hone, so to speak, to their tool.  It sounds like the possibilities are growing.  In general, they should look at any of the tasks that professional programmers are spending too much time doing, and dream of simple ways to shorten the process.  Then recognize that breakthroughs are often made by outsiders, those who don't know that something is "difficult", think here of the bright, non-professional, shareware developers.  It is true that a team has to work within a limited scope, but they can also design, within any scope, tools that are reusable, so others and they themselves can later extend the scope of productivity.

Thanks for all the good work!

# Zac Woodall said on November 29, 2007 8:15 PM:

Well said Frederick!

# clintc said on November 30, 2007 12:05 AM:

Gianni Zanetti,

I would like to understand more what development you have done against SharePoint and your scenarios. Would you mind sending us more information about how you would like to use the runtime offline against SharePoint?

http://blogs.msdn.com/access/contact.aspx

# Gilad said on November 30, 2007 1:09 AM:

Dear Zac and Fredrick

I appreciate your comments very much.

But I feel that my initial complaint has been diverted into a theoretical and sometimes vague discussion (maybe for good reason).

Yours is a very interesting and important discussion, but not the one I intended for. I have a very tangible down to earth problem and I would not like to have the subject changed.

Let me stress: I do want to read more about what you are talking about. I do find it very interesting and engaging. But if you want to tie it to my initial post then you would be missing my point. To reiterate my point:

1) I have a shareware application I want to deploy. I find with the current state of Access, that this can be very difficult.

2) To support my claims above I bring to you the fact that the rest of the community of developers of similar shareware applications has almost always not elected Access as their platform.

3) I think this is a problem that can be solved by changing a little bit some of the priorities of the Access team, and by devoting some thought into making Access more easily deployable.

4) I think and hope it will be worth while for developers, but also for Microsoft.

There

Now I feel better

Thanks

Gilad

# Brandon Smith Daigle said on November 30, 2007 1:35 AM:

Hi Zac,

I'm sure I know the answer to this is "can't say at this point," but I'm curious to know where you see the focus for future Access releases.  With the retirement of Data Access Pages and introduction of SharePoint integration, it seems clear there is a strategy to continue exposing Access data via the intranet.  Will Access 14+ focus more on SharePoint services than core Access functionality (forms/reports/VB)?  

# M. David Matney said on November 30, 2007 1:50 PM:

As it relates to the Gilad conversation.  I have to agree with Gilad on many many points. Whether you choose to package a product with Office doesnt' make it end user friendly.

Access is not even close to end user friendly and you will make it that way.  The simple concept of data normalization which is the very basic of database design (forget the app, Im talking just creating a proper ERD or DFD) is something end users cannot grasp.  

I know so many users of office that still press enter to end a line just like they would on a type writer instead of letting the line wrap and using enter for only paragraph markers. Or users that put multiple carriage returns to start the next page instead of a page break.

Come on Zac, do you actually think people who can't even figure out how to use a word processor can actually design a successful application in Access?  Granted not all users are as incapable of user Word, but the point is.  Access is not and never will be an end user application. It is a RAD tool.  

If anything Excel is much easier for end users to figure out and create a database, because most end users are not going to normalize and they are going to simple create one record for each data item no matter how much relational duplication occurs.  And then they are going to create excel forms on top of it.  If they are even capable of doing that which is fairly complicated.  

So Disagree with how microsoft views access as an end user application in the least.  Its not, and really shouldn't even be part of Office as a product line.  It should be its one development tool and sold and marketed as such.

keep looking at who posts to these blogs and other sites.  Its always developers.  that should tell you who your market is.  

# zen said on November 30, 2007 2:54 PM:

Gilad said:

"1) I have a shareware application I want to deploy. I find with the current state of Access, that this can be very difficult.

2) To support my claims above I bring to you the fact that the rest of the community of developers of similar shareware applications has almost always not elected Access as their platform.

3) I think this is a problem that can be solved by changing a little bit some of the priorities of the Access team, and by devoting some thought into making Access more easily deployable.

4) I think and hope it will be worth while for developers, but also for Microsoft."

---------------------------------------------------

IMHO you can solve you problems with these scripts:

www.sagekey.com

Bye

# Zen said on November 30, 2007 3:13 PM:

Zac, this blog is attended only from DB-developers.

I never experienced end users to be able to use Access (at first DB normalization, SQL, Joins...)

Bye

# Zac Woodall said on November 30, 2007 6:16 PM:

RE: Gilad

Yes, sorry about that.  We did get a little off topic.  I hear what you're saying, and I agree with your assessment of the current situation.  That said, I'm dubious about what investments Access could make to be a really compelling player in the shareware space.  My gut is that this is a slippery slope that would resolve into a major engineering investment and that to do it right would mean sacrificing goals we have around making Access better at helping expert business users address their needs (which is a much larger group of customers).  

That said, if you've got specific deployment issues that the wizard doesnt help you with, I'd love to hear what they are!

RE: Brandon

What you're going to see in 14 is a continued focus on making Access easier to use while at the same time drammatically better integrated with SharePoint.

RE: David

David said: "Come on Zac, do you actually think people who can't even figure out how to use a word processor can actually design a successful application in Access? "

Nope, I absolutely don't.  See my comments above: "In fact, I'd go even farther to say that it already takes a really savvy computer user to be able to create table schema and queries in a meaningful way. "  That said, I also don't think you need to have a bachelor's degree in computer science to create an Access database.  

I do talk to a lot of customers, and from my experience I can tell you that the readers of the blog tend to be much more technically inclined than your average Access user/developer.  I totally agree that it takes technical know-how to be able to build any Access application, but I also think you folks here are more skilled than the average user creating Access databases.

# Steve Palm said on November 30, 2007 7:28 PM:

I also agree with Gilad on many points.  The deployment of the Access Runtime has always been tricky but it has gotten better since the earlier versions of Access.  I have invested hundreds of hours bullet-proofing the installation routine we use to deploy our accounting solution with Access.  At least I have the luxury of editing the installer I created for other Access applications I deploy but I think for most of the other developers this is a real pain.

What would be great is a way to compile an MDB into an EXE that would have everything required to run on Windows XP and newer or include the Access runtime in Windows like you do the .NET Framework.  If neither of those ideas are possible, how about an extremely easy yet powerful wizard or application that could generate or compile an MSI based installer to deploy the Access runtime along with an MDE.

On the topic of developers verses end users of Access, what if you were to include a standard edition of Access in with Office and then a more powerful Developer edition outside of Office?  There are so many editions of Windows Vista and Visual Studio, why not do something similar with Access?  The standard edition could focus on end users with tons of wizards and templates where the Developer version could include higher end features for the developers.

# Gilad said on December 1, 2007 4:31 AM:

Steve and David, I really appreciate your comments. I find it very helpful that more developers provide their input to this discussion.

Zac, thanks again for your candid response. I am very happy we both agree an investment by the Access team is needed. But I don’t really share your concern about the “slippery slope” you mentioned. I believe this would be a marginal investment compared to the new functionalities you are planning. Look for example at the success of Inno setup installer, developed by Jordan Russell. Although I have not had a chance to use it my self yet, I read about it and plan to give it a try. This is an installer developed by one talented individual. Talk about David and Goliath. Can’t Microsoft develop and installer for Access?

You say that making Access deployable will require “sacrificing goals we have around making Access better..” and again you mention the target of the end users. Yet I noticed that some of the changes in Access 2007 only make it more complicated for the end users and not vice versa as you claim. For just one example, in order to really take advantage of the ribbons one must now learn XML. They do not have an object model to use via code. Manipulating menus and toolbars now require code. I know the ribbons have been discussed enough so I don’t want to open this again here. I am just giving this as one example of the contradiction between on the one hand targeting the end user at the expense of the developer, yet on the other hand doing the opposite, making things more difficult for the end user, while still ignoring the more basic needs of the developer.

The priorities of the access team needs revision in my opinion. To repeat what I wrote before, it is more fun to introduce new exiting incomplete features that entail breakthroughs and vision for the future, rather than to undertake the more arduous task of making the existing features more complete and robust, so that they can become a permanent part of access, can be trusted to stay and can be deployed.

It’s like introducing a new model of a great car to the market with a new incomplete type of breaking system. It may work, it may not work, but who cares. Mostly end users will play with it within the confines of their company lot, never going above first gear, so it’s not that critical. Alternatively, for any serious usage expert drivers will be hired, which constitute a very small market for the very few businesses who can afford it. I believe Access is not a toy and deserves to be treated with more respect. So do the customers using it. It is indeed a great car almost ready for the road, but needs finishing touch, and has needed it for a decade. (Sorry for being so poetic. I am trying to pass a message here ok?)

I don’t agree that making it deployable is “a major engineering investment”. I think it is an important and feasible investment that makes good sense and will increase the number of users enormously.

My opinion

Gilad

# Zen said on December 1, 2007 6:54 AM:

Gilad, you can deploy Access applications with this scripts:

www.sagekey.com

Bye

# SteveGoldring said on December 1, 2007 8:17 AM:

Gilad,

If Access were everything you want it to be, the role of Windows Forms would be tiny. Last time I checked, Access code-behind is still VBA (read: lifetime uncertain), and Access is a 32-bit program (read: lifetime uncertain). Like any other fool I am getting excited by possibilities of Access 14 - how many months or years before we even see it?

From my experiments with 64-bit Windows, I won't have it as my desktop for a long time. But if business moves to 64-bit on the desktop, is Access expected to work seamlessly in WOW? I just don't see what is going to keep Access and VBA at the cutting edge.

Steve

# Vladimir Cvajniga said on December 1, 2007 5:58 PM:

Gilad,

thank you very much for your input. I hope the Access team will concern on deployment issues as well as on ergonomy.

About Zac Woodall