Product Team Status Update

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

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.

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.

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.

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?

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

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.

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? www.access-programmers.co.uk/.../showthread.php

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

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.

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 blogs.msdn.com/.../a-chance-to-influence-the-direction-of-access.aspx. I've e-mailed him Oct 18th 2007.

Guest: TYVM for the link! :-)

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.

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?

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.