From: Albert D. Kallal on
"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
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
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
"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

"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.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10
Prev: Problem with query
Next: Append Query error with apostrophe