how do i build a website using access 2010?

Question

has anyone done this yet? please show me some good tutorials on building websites with databases using ACCESS 2010

you can build a website using it: http://www.youtube.com/watch?v=AU4mH0jPntI

Answer 1

There's a whole bunch a really excellent tutorials and getting started on this process, on the access team blog here:

http://blogs.msdn.com/b/access/archive/tags/access+2010/

The above link will filter by access 2010, and a rather large portion the above articles pertaining to access web services and development.

For the most part you'll find the vast majority of the challenges when building a Access web site, is in fact not learning access web services, but learning HOW to think in terms of web based architecture and design. In many ways, somebody who doesn't know what they're doing potentially will have less frustration with access web then a longtime access developer.

I should also point out that the access client mmeans you don't need any server or any other tool set up to get going. You can an do develop 100% inside of the access client as you've always done. So you don't even have to set up any database server, or any type of server at all (you'll eventually need one, but not to develop the application, only a place to publish it once you're done). You just fire up the access client. Just make sure you create a web database as opposed to a client database, and you're off to the races.

As mentioned, the hard part is not learning how to build forms, and you'll likely are capable of doing that now in access. The hard part and challenge is this change in conceptual thinking.

I mean for almost all of my computing career, I'm used to having a form and you click on a button and it simply launches another form. You close that form, and you return back to the previous form. The problem here is, when you go to a web based architecture, launching another form in theory means you're going to launch another copy of the web browser. The problem here is that, what happens now if you close the first form? You now have a simple form with no application navigation and this second copy of the browser has no way of returning back to the previous form that you came from (which as we now know was in fact a browser).

So, if you have 5 different web browsers running on your desktop, that might be 5 different web sites that have nothing to do with the access web site. It is these simple but not so obvious concepts that one not had to give ANY thought about for so many years that was the big challenge for me. In fact, it took me about two full afternoons to finally start to "think" correctly as to how program navigation would work.

Again, this was not a hard concept, and it was not some big access learning curve. The issue was I not had to think about simple dead obvious concepts like forms to forms and program navigation in many years. So the big challenge here is a CHANGE in conceptual thinking, and changing how you've done things in the past. If you try to do everything like you've done in the past, that's where you're going to fail. The important concept here is this is a true web based architecture system. If you're not looking to do a web based system, then you would be better off to use something like terminal services.

Realistically, when you get over the psychological hurdles of how web flow and applications have to function, then you do get much leverage out of your basic access skills.

Another significant challenge and change in mentality is moving out most program logic and code from an access web form. It's probably significant to point out that when you start building an access web form, you'll be in the state of shock as to the lack of functions available when writing macro code for that form. The reason for this of course is that that form actually is going to run inside of a web browser on the users desktop. In fact any code you write inside of the form will actually get converted and runs as JavaScript inside the web browser. The resulting architecture is as follows:

At the end of the day I don't think you need to know and realize of the above architecture. However the above architecture explains why you have such a limited function set when you write code inside of a form in access web services.

I just posted an article a few days ago on how you can write and implement a soundex routine. With great ease, I built the following form and code that allows you to search names by how they sound, as opposed to the spelling:

Notice and the above web form I created in access, note how I typed in the name Cindy, but note how the search matches names that sound the same, but their spelling is different showed up in the search. I used Access to write all code for this form.

An article, and even a sample database you can download and run, is outlined here:

http://www.members.shaw.ca/AlbertKallal/searchw/WebSoundex.htm

Note that you can run the above sample web database inside of the access client needing nothing more than just access 2010 installed on your pc.

So at the end of the day, I could really argue that for the most part you really don't have to learn a lot, but you will have to learn the new data macro programming language, you'll have to learn to "think" in a new architecture, and for application navigation, you'll have to learn and use the new navigation control.