Office 2010 .Net developer blogs about Access 2010

[shihkjh453]

So how has my experience with Access 2010 been? Exasperating, frustrating but undeniably productive. I am not sure it is the right product for an ISV style company who want to roll out a single solution to many client sites (but it could be used for this if needed via the SharePoint site template ##############); but for a smaller data driven site (with or without custom extensions) written within an IT department it is a very strong contender. Taking Access in many ways back to its roots.

<div
But equally, by treating Access as just a data format I was not able to make use of it as the Rapid Development tool it is. I was too hung up in the unpleasant idea of an MDB sitting of a server being poor at locking and saturating the network with unwanted traffic. I was not even considering Access as a front end to a MS-SQL solution, and it is not as if that is new technology, it has been around for ages. I was just sitting happily with my prejudices.

Actually the bulk of the time I have spent has been on looking at how you can extend Access Services to reach that last 20% of functionality,Office Pro Plus 2007 Key, and it not that hard. The key to remember is that the Access Services are just built on standard SharePoint objects. Ok, there is a new service running to render the pages, but underneath there are just SharePoint lists and workflow, and where these exist there are events that you can programmatically handle. I have found that by trapping events such as ItemAdd() for the Access-created SharePoint lists, there is no real limit to what you can achieve via the SharePoint Object Model. And this development process is made even easier by the new Visual Studio 2010 templates for SharePoint features. If nothing else the fact that all the templates create a WSP for deployment makes for far more robust feature development.


So if you need small data-driven sites I would suggest you put aside your prejudices and have a look at the beta program for Office/SharePoint 2010. I think you will be surprised.
So how has this new technology been working for me? Well I can’t say I have grown to love the Access client, but I think that is mostly down to that fact that I am still not thinking right for it. Access is all about data binding. You don’t have to think about what form fields need to be copied to which DB columns, and the wizards make a really good attempt to design forms for you based on the relationship of the tables in your DB. This just all seem unnatural to me. I think this is because I am usually working with design patterns to reduce the linkage between forms and data to a minimum (e.g. the MVC pattern), and so consider this good practice; automated data binding seems wrong. So in Access, I want to build things from first principles, but this is just not sensible. Better to let the tool get you close and then you add the polish, and put away any thoughts of implementing design patterns as you would in a language such as C# or VB.NET.
There is one major difference between a standard SharePoint site and one created by Access, and it is that SharePoint Designer cannot open the Access site. I thought this would be an issue when I first heard about the limitation, but it turned out not to be. Anything you might have wanted to do in SharePoint Designer you can do quicker and easier in Access for this type of data-driven site. Ok the range of things you can do is more limited, but again you get that 80% you need with much less pain.
Clint
make use of the newer lambda expression based syntax of LINQ make use of newer ORM solutions such as Entity Framework or nHibernate.

But wait! Look at the benefits. A while ago I was involved in a project to provide a resource management data-driven web site that was hosted within SharePoint. It contained the usual things--data entry forms, links to SQL and reports. It took a couple of weeks to build. I think I could write the same system in Access with SharePoint 2010 in an afternoon, and would be happy to have a client’s business analyst sit next to me while I did it,Cheap Office 2010, in a pair programming style, to design the forms, report layouts and columns as I went along. For the smaller scale data-driven site, Access Services is a great tool, but obviously it is not perfect. I do keep hitting points where I think ‘if I were in C# I could just do that,’ but then I remember, ‘yes, but it would have taken me three days to get there, not an hour’. Most projects don’t need that last 10-20% you can only reach on .NET custom code,Windows 7 Activation Key, and the client with be far happier with 80% done quickly and flexibly rather than 95% done later. Also we have to factor in my relative lack of experience with Access as a RAD tool, reducing the productivity that could potentially be achieved by a more experienced Access developer.
Like most .NET developers, I had looked at Access as more of a file format than an application, something from the past. Something that I might use for a small data store, maybe in a web application hosted on a cheaper ISP that does not provide ‘a real’ SQL DB, or where an XML data files don’t seem right,Microsoft Office 2010 Home And Student, often because I just can’t be bothered to work out the XPATH. When using Access as a data format it seems easier to get at my data using basic hand crafted SQL commands or maybe at most via a OLEDB Data Adaptor/DataSet. All very old, old school. Thinking about Access in this way just seems an easy way out, playing it safe with the knowledge I have. I don’t for a second propose that this is a good idea. You should not be looking at using any technology just because it is there and you already know it. There are obvious downsides, using Access in this manner meant that from the ADO.NET developer side I could not:
____

Richard is not someone you would call an avid Access developer. He recently wrote about his experience building an Access application on SharePoint. I have reposted his article here with his permission.
Today’s guest writer is Richard Fennell from Black Marble. Richard is engineering director for Black Marble, hard core .NET developer, and MVP for Team Systems. Black Marble does a lot of custom SharePoint development and sell few accelerator kits. Black Marble is active in the community sponsoring regular .Net developer and SharePoint conferences and workshops. They have worked closely with our team over the last couple months as part of the Office 2010 Technical Adoption Program. 





Updated 10/22/2009 with minor grammar edits.
Access Services in SharePoint 2010 or: How I Learned to Stop Worrying and Love Access 2010
I think this is the key to the degree of irritation I feel with the product, if you have got used to architecting from the ground up, especially in a Test Driven Development style, you have to turn everything on its head. It feels like you are cheating, and not doing the job properly.
So what I have I been doing of late? The blog has been a bit quiet. Well I have been having a good look at Access Services in SharePoint 2010. This has been an interesting experience,Office 2007 Serial, as I am not historically what you might call an avid Access developer.

I don’t think this position is that rare for .NET developers these days. Access seems just looked down upon as something old in the Office pack that is best ignored, and no good would come of using it in a business environment.
So enters Office 2010 and SharePoint 2010 Access Services. For me this changes the game. For those who don’t know this technology, you can create an Access database locally on your PC then publish it to SharePoint. Tables become SharePoint lists, macros become workflows and forms become forms. Access becomes a RAD tool to create data driven SharePoint sites.