Sounds like Access 2010 is something of a different animal from
preceding versions.

Could anybody generalize the big issues?
--
PeteCresswell

(PeteCresswell) wrote:
One starting point would be to browse Access team's blog.

http://blogs.msdn.com/access/default.aspx

Click on "2010 Intro Series" tag, which is high on the top of the tag
list and you'll get plenty of general info on what's new to 2010.

"(PeteCresswell)" <x@y.Invalid> wrote

How big of post do you want?

Perhaps the big news is the new version of VBA, or what we call VBA 7.

This new version of VBA now has a true pointer data type called longPtr. We
also get a 64 bit wide data type called longlong. There's a few new
compiler definitions, and of course we get a 64 bit version of the jet
engine (now since 2007 called ACE - for the remainder this article I'm going
to use the term JET, but I really talking about ACE).
Note that this new version of VBA of course is also runs on the 32 bit
version of windows.

->Database triggers and stored procedures:

New for 2010 in jet is table events and table stored procedures. When you
write table triggers for jet, even on a file share with five users (split
front + back end), and someone opens up one of those files directly, or even
with VB6 via ODBC if they update a row, then your table trigger stored
procedure code will run and fire. In fact you don't even have to have a
Access installed on your computer. This is a true engine level store
procedure and trigger system. If you attempt to open accdb file in access
2007 and you have table code attached as events, you will get a warning
message that there are triggers for this table, and the table be opened as
read only.

I'm starting to write some table level procedures, it really is a terrific
feature, and it does move logic out of your forms. It also means that you
can maintain some totals like inventories etc. So, if you update this data
through a table direct, through DAO recordset code, or have five different
forms - it simply does not matter, your aggregate totals will remain intact.

->New macro editor + new macro language:

While the macro system is able to execute old commands, you now have an
if+then+else block structure language that includes the ability to loop,
declare variables and also that of being able to update and read records in
a table. It is this language that's used for the above table triggers. So
the new macro language and new editor is a system we use to maintain + run +
design and build those table triggers.



->New Web browser control:

This is a fantastic control. In fact this probably is near tops in my
favorite new feature for 2010. We can now embed a browser control into a
form and this is a bound control to a column in the table like any other
control from the toolbox on that form. If you've not see my bookin video
(link later on here), you'll see how I used a bound browser control inside
of a form to show the current weather outside for a patio that can be
booked.

->New web style navigation control:
This is simply a browser WEB like navigation control that you typically see
in so much software today . Even the Acronis disk imaging tools for the
desktop has a very similar navigation control. You can stack this control
going horizontally across the top, or up down on either side of your forms.
It looks really nice and certainly is about time that we got something
beyond that of the old switchboard that has been around for far too long.

->New button and tab styles.
For buttons and tabs, you have the ability to create round, oval and shaded
buttons with shadows, glow features. the "hover" options also thus can be
set as for color and effect also. With these shading and transparency
controls, you can now give your application a modern look. Here is a
composite screen shot of what this looks like:

http://cid-b18a57cb5f6af0fa.skydrive...mlistround.png
and
http://cid-b18a57cb5f6af0fa.skydrive...ng/RoundB1.png
and
http://cid-b18a57cb5f6af0fa.skydrive.../ButtonsOP.png


->Ability to drop reports into a sub form control.

This means we can make some pretty cool - cordite displays where some form
action displays a report in the form.

->Shared images:

When you insert an image into a form , we are used to having two options
(imbedded, and linked). You now see a 3rd new option in the combo box drop
down called shared. If you choose shared, then the image choice becomes a
combo box drop down of all the currently existing images in your
application. This means you can use the ONE same imbedded image over and
over again in the application. Even more cool as that this means only one a
copy of the image exists and you can change it and thus every part within
your whole application that referenced that shared image will also change!
Access 2007 address the image bloating problem when you insert images inside
your application, now this goes one step further and allows you to share
those images you've inserted into the application. This works really great
for client based applications, but also was a great feature when you're
building web based applications. So for things like company Logos etc.,
this is ideal, because then you can change one and it changes everywhere
because it's not really everywhere.

And if you don't use the Manual way of inserting an image, there's also a
new option on the ribbon that allows you to see and view and insert all you
shared images. It is a ribbon gallery. Here is a screen shot:
http://cid-b18a57cb5f6af0fa.skydrive...ing/imageG.png

-> Application template parts:
This simply means you can go raid a bunch of your old applications, and take
bits and parts out, and save them as separate new applications that appear
in your application parts as templates. You can even have the insert option
prompt you for what table to insert and relate to this new "application
part". Here is a screen shot, you can see that I already have an insert
option for my custom calendar:

http://cid-b18a57cb5f6af0fa.skydrive...ing/aparts.png

So not only can you define things like the icon you'll see in your template
gallery, you can also define the action such as including tables, and things
such as prompts for what the included tables will be related to in a current
application that you're inserting the table and application parts.

->Web based applications:
The other big news is that we can now create browser neutral WEB based
applications when you published your Access application to the web. All of
the above features from triggers to shared images, new navigation control
and even a web browser control also work when you publish your applications
to the WEB. Here is a video of me running a Access application, and then I
flip at the halfway point in the video to running the same application 100%
inside of a browser:

http://www.youtube.com/watch?v=AU4mH0jPntI

The above is a short list of new features, but they're all ones I've used in
ones that are basically sitting on the top of my head, there's a lot a
little lines and a lot of other features of Ms., but I have to run right
now..so I stop...


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com

On Thu, 8 Apr 2010 19:16:28 -0600, "Albert D. Kallal"
<PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote:

In his enthusiam Albert meant to say: ...when you write your
application for, and publish to SharePoint.

-Tom.
Microsoft Access MVP

Albert D. Kallal wrote:
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.

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?

"Salad" <salad (AT) oilandvinegar (DOT) com> wrote


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.

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 (AT) msn (DOT) com

sorry, using voice dictation here:

so:


> now ridden development is far faster = now ribbon...

sorry, using voice dictation here:

so:


> now ridden development is far faster = now ribbon...

"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

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote

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.