SharePoint Apps Offline and Intro to SharePoint Designer

Erik,

Some of the hard core developer folks are giving you quite a time on this blog. Just want you to know that there are some of us that really love what the team has done. The new report layout mode, attachments, filtering, SDI, and filtering are great features. I really love the look of Access applications. It is great to say good by to the dated 3-d look. Tranparent images are so cool!Your new templates are great starting points for some of the scenarios I was thinking about building a db for. Have you considered building a inventory template? I'm just aobut to start a template to track lending laptops in our department. It would be great if you could provide a starting point. I don't see how someone could think MS is killing the product after making such a huge investment. I do miss the security for Access databases but never considered using replication--what you have for SharePoint seems to fit my needs but I haven't played with it that much yet. I don't know anyone who uses replication... Keep up the good work--some of us out here think this is a great release.

Colt, thanks for the good word! Yes, we'll have templates for both inventory and "lending libraries". As you might imagine, we're quite excited about this release for all the reasons you mention. Change is hard, I guess. Thanks again.

Yes, there certainly are some nice features in the new version. I personally would want to upgrade for the report designer improvements alone! Designing reports was a real bottleneck in RAD process (despite still being faster than most other systems out there!). It is, however, a mistake to marginalise the opinions of professional developers. I contend it is actually the developers that drive the widespread use of MS Access on the desktop today. I have been working with MS Access since v2 and as a contractor I have worked with many government and corporate organisations as well as SMEs, and microbusinesses. I certainly have a pretty good idea of how the product is really being used out there in the real world. While I have certainly seen (and had to reprogram) many Access apps that were written by non-professional developers, it is far more common these days to have the use of MS Access in the organisation driven by the developers in the first place. In other words, MS Access is on the desktop of most users *because* they need it to run the inhouse MS Access apps that have been developed by professionals (or by non-professional staff quite some time in the past). It is much rarer these days to see new MS Access databases being cobbled together by non-professional staff. Generally, MS Excel is used for this purpose nowadays (for better or for worse). In fact, many IT managers forbid development of MS Access apps by non-professional developers. At the same time, a large portion of these are pragmatic enough to see that MS Access is a tremendously productive tool (in the hands of a professional) for developing many inhouse apps. Even more so than .NET! So, while there may indeed be many non-professional users of MS Access, the bulk of these really are simply users of the existing inhouse applications that have been written in MS Access. They don't do any development in MS Access themselves and, in many cases, don't even know that Access is installed or what it is. They think in terms of the inhouse application itself and not the product it was written in. Even if you do make in easier for novices to use, I think you will still have a battle convincing IT Managers to allow non-professional developers to create Access apps, because of past bad experiences with this. Therefore I strongly believe the key to maintaining a strong MS Access presence on the desktop is by making it a strong development tool, not by watering it down! Chris.

^^^What he said^^^ And don't forget ADPs - the only dedicated SQL Server front-end tool on the market. And remember, ODBC (as used in mdb or ACCDB) does not support application roles or Windows authentication - the MS-recommended methods of securing client apps. You can only use app roles and WA with ADPs. So if you want an inherently insecure app, go ahead and use an mdb or accdb. As for all the other great features - I'll be very glad to use them, so long as they are supported in ADPs. Otherwise, I 'll have to do without. I'm still waiting for y'all to support secure app roles and W.A. over ODBC in accdb's.

Need to find out how we can use an MDE file that usually accesses an MDB database file; and convert the MDB file to a SQL MDF. Do we have to use an Access ADP in order to do this? Please can you offer some advice on how this can be done and how it can be done? Please contact me at joe@kccsoft.com Regards. Joe Francis

Chris,

Thanks for taking the time to share your opinion and you are absolutely correct. Developers are really important to Access and create many applications our end users love. I have been on many customer visits where a developer is instrumental in creating the app that drives Access deployment. I have also seen many customer visits where that developer wasn’t a professional developer but someone who was taking a class, reading a book, and studying the help file. Every single day new users start the long road of becoming developers. We want to make the process of learning how to use Access more natural and intuitive. One of the hard thing and exciting challenge about our job is balancing investments that span new developers to the most advanced hard core folks. We also think templates are really, really important for end users. Last year there were over 2 million downloads of English templates. There is a great opportunity for us to provide more and better content that delights users and gets people using a database that is a good starting point. We have found end users are far more successful modifying (especially adding a field or two and creating reports) a well designed database than creating one from scratch. The team is finishing up work on a tool that will make it really easy for developers to create templates from their own databases. These templates can be deployed and show up in the getting started experience. I agree with you that there are many simple databases that are kept in Excel that should be inside Access. We are trying to make it easier for those applications to be Access applications. We haven��t invested in this area for quite a while and some of the improvements we have made in this release will definitely help people ramp up on developing databases faster. That said, I don’t think we have some great developer features– have you discovered control anchoring? I think this is one great developer feature that makes it much easier to build apps that take advantage of screen real estate. Here are a few of my other favorite developer features: PDF integration, native rich text, native date picker, alternate row color, better hyperlink support (display as hyperlink), improved image support (don’t bloat and transparency), images and text on buttons, etc. Fortunately, for my job stability there are still lots of things we want to do for developers in the next version. Joe,

You have a couple choices to move mdb data to SQL Server. There is the upsizing wizard in the product today or the SSMA tools provided by SQL Server. You don’t have to create an ADP to have your app work with SQL Server. Access 2007 upsizing wizard moves the data and by default creates link tables to SQL Server. It does provide the option for an ADP but it isn’t the default anymore. I recommend you take a look at the help documentation on the upsizing wizard. The SSMA tools have more knobs on the upsizing process. There is quite a bit of documentation about the SSMA tools and free downloads available: www.microsoft.com/.../default.mspx

www.microsoft.com/.../details.aspx

Clint, I hope you are going to fix your Access07 pseudo “database” templates and abomination that you call “Move to SharePoint”. You see, I went and looked at the very first template, called “Assets”. I suppose that unsuspecting users like Colt (above) might think that this template actually represents a real database, a database that might use Codd’s rules to some small degree to prevent all kinds of nasty anomalies. It’s from M$ after all... But, he would be wrong and in for a rude awaking as to how M$ is hocking this crap as an asset or inventory “database” application. He would be very wrong in the case of “Move to SharePoint”. If the template is used before it is moved to SharePoint, Colt MIGHT have a chance of keeping duplicate data from causing confusion and bad reports, but after it moves to SharePoint, all bets are off. If he has users that actually use the SharePoint site and create entries, his Asset “database” will quickly turn into a pile of dung courtesy of the M$ Access team. A future story... Lets see, I put Clint’s name and Erik’s name in my new 300$+ Access 2007 Asset template “database” here, but somehow there are now two Clints and so I went and change the user ID for the second Clint, but now I found a problem with Sues laptop. Some how it got inserted 5 times (she is always in a hurry and did not know to single click or to double click on the SharePoint “Save and Close” button after entering her data, so I found out she must have clicked it twice, then again and again twice before hurrying off). But now, Erik did not know that there is a “next” button after 10 records on SharePoint, so Erik duplicated his assets and now Clint says his inventory is wrong, again, maybe its that darn in-your-face ID again... Ok, now the reports are messed up again… Man, I wish would never have bought this Access abomination from M$. I thought M$ would know how to make a simple database with two tables work right!! It seems they spent more on coffee, then on making Access work right... A nightmare brought to you by the Access 2007 team.

Well once again I feel compelled to make the comment that it seems the only time responses are made by the project team are when some positive feedback is given. Here we see developer after developer registering complaints and questions and no response is given. My question is...What is the purpose of this blog if most posts are simply ignored? Clint states that "Fortunately, for my job stability there are still lots of things we want to do for developers in the next version". How about doing the things that developers are asking for IN THIS VERSION?? Clint, most of the things that you point out as developer improvements (like PDF integration, date pickers, alternate row colors) I have been doing for years in Access with a little code and API programming. And your comment about "makes it much easier to build apps that take advantage of screen real estate" is interesting. Any gain is screen real estate is more than compensated for by the bloated space taken up by Ribbons. Templates? I would never consider using them since they do not fit the standards that I've developed for my apps over the years. Truly, the features for developers are trivial and in many cases NOT was asked for. I'm not very familiar with Sharepoint but based on comments here, it appears to be quite the kludge. No referential integrity or unique indexes? Very limited capacity (like 10,000 records)? It boggles the mind. I'm apologize for the negative tone. In some cases on this forum it has gotten TOO negative. But this comes from the very real frustration which seems to be shared amongst many developers who know the power and flexibility of Access, but are witnessing it become an ineffectual tool for that particular community. Maybe end users will be happy. Serious developers clearly are not.

Stepup, Mikec#, and others expressing frustration with Access 12, I understand that you are frustrated and I feel bad about that. I've tried to address this frustration by explaining why we've built the product we've built, what our goals are, and why we're excited about the future of Access. I've stated these things a few different times and in a few different ways and haven't made you feel any better. So, rather than having both of us hurl the same messages back and forth, I stopped. I care a lot about what you think, I understand your points, and I'm sorry that you're frustrated by the product. My challenge is that I don't seem to be able to say anything that will ease your frustration. If there's something I can explain, let me know either in the comments or in email. Thanks, Erik

StepUp,

You asked about features this version. Access 2007 is pretty much done. We are in the final weeks of polishing this and now starting to think about vnext. It isn’t possible for us to add major archictectureal features this close to shipping. There are many, many customers very excited to start using Office and Access 2007. About SharePoint--the data model is different than what you would expect from SQL Server. The reason data is stored in a sparse table is because it scales very well to scenarios where you have tens and hundreds of thousands of individual lists. We know from existing SharePoint deployment that users create many, many lists. We understand developers need more functionality in the platform layer (e.g. referential integrity, server validation rules, etc) to build more complicated applications and are looking into further improvements to the platform layers. I do believe that end users and developers want to build applications that have server and rich interfaces into the data. Most of the time when I talk with customers this issue comes up. SharePoint is definitely a big long term strategy bet for Office (one that is doing very well right now). Did you know SharePoint is the fastest growing server business in the history of MS? Also, OfficeLive is built on the SharePoint platform. There are some great services the data model does provide. Every list is exposed as RSS feeds. Users can author lists without rights to create tables on the SQL Server. There is a permissions model for editing schema and data that is site specific. Many list types can be taken offline in Outlook. Users can get notifications when a list changes. We make heavy use of the GetListItemSinceToken API to only request changes from the server and synchronize offline changes. If you are running your app in Cache List Data mode you will notice far less server traffic. WRT – templates… We don’t expect all developers adopt our user model for templates. That is why we built an extensible architecture and getting started experience so that you can create your own templates that model your user model and user experience requirements. There will me more information about how to generate templates posted later.

Do Access 2007 works fine in Microsoft Terminal Services environment? Bye

There are a lot of us that would like to hear some official commitment re continued support or future plans for current technologies. IOW, are the following technologies going to be deprecated or unsupported or replaced in the next version (i.e after Access 2007): ADPs - and keeping ADP features in sync with accdb

Security in mdb/accdb

.NET coding integration

DAP (publish to web) replacement strategy

Replication strategy

legacy CommandBar model These are questions that our careers depend upon. Please give us some straight and reliable answers - where are these technologies headed in the next 5 years? Thanks...

> Erik - I was referring to QUESTIONS about A2007, not comments. There have been several questions that have gone completely unanswered. I asked about the restoration of the "auto repeat" function in the navigation control, the ability to display a form in classic Windows style and also about what changes/fixes were in the technical refresh. Others have asked questions on a variety of topics that I saw no response to. Clint - Thanks for that info on Sharepoint, but I am wholly unconvinced. I can see where this is a handy feature for EXISTING Sharepoint customers, but for building a localized app the use of Sharepoint seems impractical, inefficient and far too costly. Al - Perhaps you have not been following the points in this forum. Basically, in the versions of Access going forward: -ADP's are dead.

-Security on the user/group level is dead.

-Replication is dead.

-Command bars and menus are dead.

StepUp

You are not correct on several points. I have reread this blog's posts many times, and there are many ambiguous psuedo-answers given to my questions, and to others' questions. In several places, Clint/Eric have given lukewarm support to ADPs, ACCDB user security in a possible future version, legacy support for commandbars, and alternatives for replication in Ac2007. I want to know the plans for these things beyond Ac 2007. Most of all, I need to know the real future for ADPs; I estimate the wrong decision on my part will cost me well over $250K in development costs. I have high security needs, so accdb will never cut it, and I can't continue with ADPs if they won't be supported in the next version. The best option for me is to continue with an improved version of ADP, rather than rewriting everything for accdb or .NET.

Hi AL, I have developed a few Access03 ADP applications (that are currently in 24/7 production environments). These applications work excellently – just ask my customers. I know all about using unbound forms, sprocs, security, etc. that make ADP apps work great. I went an got the 07beta (+ TR) to see what Access07 will bring. If you want to verify the following statements, go and load a copy yourself. In Access07 there is NO information about the Access Project format in the help file. The Access03 help file has a chapter, the Access07 help file has none. My Access03 ADP applications do not work in Access07 as the window title bar disappears, the window jumps up and down when opening forms, two status bars appear, the fat menu ribbon is obscene, etc. Really, until I see the basic window jumping/title bar problem go away when creating ADPs in Access07, it is unusable. And since M$ has basically cast this Access07 travesty in stone right now as Office07 is going to RTM, I will not be creating any more ADP applications in Access07. The Accss07 ADP does work with SQL Server 05, but that is the only change to ADPs that I can see. It’s possible I will use Access07 for a standalone frontend/backend MDB style app, but it’s unlikely given the attitude that M$ as shown to Access developers. Basically the only thing developers wanted and got in Access07 was a working mouse wheel in the VB IDE. People who think that transparent buttons are a significant advancement for Access07 must also think that Dubya was competent to be president of the US. Really it’s not the fault of Eric or Clint as they are just cogs in a wheel, they have developed little to no independent thinking and thus just conform to the M$ strategists and memes floating about their offices. The M$ strategists see non-dotnet VB as dead, the Access development platform as a toy (thus Codd’s rules are an afterthought), and Access is a “feature” or add-on to Office, something to promote SharePoint with. AL, it is clear, M$ has killed Access Projects. Access03 was the last version that Access Projects were really supported. With M$s track record on Access, you would be a fool to take any comments by M$ people on what Access 13 might or might not support. Mike