2010: Essential Diffs?
in [Help]
|
From: Albert D. Kallal on 9 Apr 2010 01:30 "Salad" <salad(a)oilandvinegar.com> wrote in message news:rOGdnVC_44jgBiPWnZ2dnUVZ_tSdnZ2d(a)earthlink.com... > > I am curious as to what you think of somebody in an upgrading to 2010. The > person has put together some tables, maybe used the wizard a couple of > times to create a form or report. Very little error checking. I think in a case of the person who's using 2007, I don't think the person will suffer much of a change at all. A lot of the features and concepts in 2010 were introduced in 2007, and where done to to pave the way for 2010. So, features such as the new layout control system was clearly going to be used for the WEB features in access 2010. > > Do you think A2010 is more beneficial to developers/require more developer > input or is it easier for somebody that is not as technical but has put > together a couple of small apps for the company? I think it's pretty well split. Just the other day I was telling someone that I was absolutely thrilled enjoyed that Access 2007 did not have are ridden customize are built in like Access 2010 does. The reason is because I learned cut and paste xml around, I really don't read the xml, but the development paradigm of being able to go in raid existing applications, and simply pull out xml from different places pull it all together and shove it into new application is really fantastic. We could never do that with menu bars. From an application development management point of view, and try to move parts of menu bars between applications is simply painful. Now course I probably two done this is much because Access 2010 simply allows you to right click on a Redmond, and you can start adding new groups tabs and buttons without ever reading or seeing xml. This is great, but I can tell you I'm so happy I was forced to do this long way! The end result is, and now ridden development is far faster than menu development ever was for me. Certainly some features are are more oriented towards developers (such as a new data Pointer type in VBA - we never had a data pointer type in VBA. Too bad we did not, as the switch to 64 bits would have been seamless - all well, when we jump to 128 bit computers, Access and VBA will be ready because we now have a true pointer data type). Other features will benefit end users. I mean the new shared picture feature makes so much logical sense, and is such an obvious feature I don't know why it wasn't asked for here more frequently? All experienced developers would use some link or external image so they don't bloat up the application and this allows replacement of that ONE image such as a company logo to be application wide. So an intelligent developer would demand that only one copy of that image exist in the application. A developer who is less experienced and not in thinking about the problem will just start inserting images everywhere left right and center like newbie's always do in access. However, that big ribbon gallery of images they're using is so delightful easy to use, that they'll actually be coming up with a great design because they are using the same image over and over again without really making an effort to do so. And that user interface even has provisions for allowing the user to change that image to something else, and again all parts the application will realize that change. The above example means it hard to tells who wins more, an experienced developer that sees how obvious it is for such a feature, or the person doesn't know what the heck they're doing is now doing the same design as experienced developer would anyway! The same thing goes for the table triggers. Table trigger makes a whole class of problems really easy to solve. So the lesser developer wins because the problem is so much more easy to solve. However from an advanced engineering software point of view, it makes great sense to move out program logic out from the GUI layer. The reason for a course this is that then any form or code you write will benefit from that table level logic no matter where you write it in your application. If you build one form, or 10 forms, they all benefit from that SAME table logic and updating code you've incorporated into your application. So the very nature of that table logic code forces the user to centralize his program logic in one place for all parts of the application, and that's really a great design paradigm. And in fact if you come along and are hired to write some DAO code, then that users tigger code will still run. As mentioned, I my personal favorite part of this whole process is during the prototype and developing stage. It seems that you get so much done and yet not had to build any forms and all that hassle user interface stuff. All you do is lay out the tables and start writing tiny little bits of program logic, and the application starts working all by itself. It's the smaller increments that give your brain lots of feedback that puts a smile on your face and that makes the development process oh so much more enjoyable. So any development paradigm that encourages removing program logic from the UI layer is a very good thing. Once again experienced developers will take this aspect into their designs overall, and the lesser one will do it because it's easier and they don't know what the heck they're doing anyway, but it turns out to be the right thing to do! For example we often see questions and people here struggling to write some code in the after update event of the "details" section of a sub-form to total up some value. Now one can argue that these aggregate totals should never be stored in the database. Fact of the matter is a lot of times it is REALLY handy to do so. It then makes writing of report's, and merges to word etc. VERY easy. It means that when I writing code or a report that total value is just handy dandy sitting there and I don't have stop and start writing some query or some code to total up some value each time I need it. Without table level triggers, it really was too risky to store aggregate totals. The instant you have table level triggers, then it makes sense to do so (and since this is a table trigger then it not really such a bad practice from a normalization point of view either). Once again, is really hard to tell who benefits more, but at the end of the day part of this design allows us to move code out of the UI layer into a program layer is not only good, but that's also what allows one to write WEB based applications in Access. I can't rave enough about those table triggers. They are a very conducive process to rapid prototyping. It's so cool to write a little piece of code, then just open up a table, type in a value and see the program logic run and see values update right before your eyes. This whole process makes development oh so fun again - it really does. If you not made the jump to the ribbon, and not played with the layouts in 2007, then 2010 going to be a steeper learning curve as it has more new features then any version of access I can think of... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 9 Apr 2010 01:36 sorry, using voice dictation here: so: > ridden customize = ribbon customize > right click on a Redmond = right click on a ribbon > now ridden development is far faster = now ribbon...
From: Albert D. Kallal on 9 Apr 2010 02:57 sorry, using voice dictation here: so: > ridden customize = ribbon customize > right click on a Redmond = right click on a ribbon > now ridden development is far faster = now ribbon...
From: The Frog on 9 Apr 2010 03:55 "longlong" - LOL Someone had a laugh when they made this one. I am looking forward to the A2010 release. I have not played with it yet, but on the surface it looks like a giant leap forward for Access, and also for VBA. I was not aware of the table triggers - very cool. I like using triggers and stored procedures in other db systems, especially for controlling data entry. All data available through 'views' and data entry through stored procedures only - no direct table access. I wonder if that is possible now with Access 2010? We shall see.... What is happening with A2010 development? If one wishes to professionally develop apps in A2010 what do we require? Is there a developer edition? Do we need some form of visual studio? Is it .Net integrated? Is there a decent reference on the new macro language and the new version of VBA? Decent training materials for the application itself? Certification as a developer possible? Lots fo questions I know......(I feel like a thread hijacker......oh wait......I am hijacking......but since we are on the topic......). Cheers The Frog
From: Allen Browne on 9 Apr 2010 04:09
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in message news:k3zvn.75691$NH1.69923(a)newsfe14.iad... > sorry, using voice dictation here: > >> ridden customize = ribbon customize > >> right click on a Redmond = right click on a ribbon > >> now ridden development is far faster = now ribbon... LOL, Albert! Do you know how to get Redmond to act, so we are ridden of the ribbon? :-) -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. |