Will said:
1 - It seems that we must go with Access 2007 to be able to create runtime
files... and distribute Access data bases to users who do not have
Access... right?
No, not at all.
A package and runtime system has been available for more than ten, perhaps
fifteen years of MS access. I can see you are difficult position, you're in
charge of a bunch of access applications, but are walking into uncharted
territories (else I have to assume you would have at least heard of the
runtime system). I can certainly understand your difficult challenge here.
You as a general rule should normally use the runtime system for the
particular version of MS access you been developing with.
It is not a good idea to take applications and just willy nilly migrate to a
different version that you've not used, and then expect to not have any
deployment problems at all.
I recently took an access 2003 application and converted it to a2000.
(access 2003 lets you convert to previoues versions). I was amazed at how
many little replot bugs, and other little issues came up. What occurred here
of course is that the a2003 fixed a lot of bugs and little problems and
little quirks that had been discovered in access over the last few years. If
I had been developing access 2000 all along, then I would saw the replot
problem right away, and would have modifed the code, and played around
untill it worked.
On the other hand I took another application of mine with 160 forms, and
30,000 lines of VBA code from access 97, and converted it to access 2003. I
did not really have one issue except for the slight change in the message
box format that occurred from access 97, to access 2000. (we lost the bold
"@" formatting option that access 97 had when a2000 came out. So, for the
most part you'll find applications convert quite well up to the next
version, but often a few little issues and quirks come up and you fix them
along the way. In some large applications, or if you have many many little
applications then a small problem can rapidly become a very large amount of
work for you and consume a lot of your resources and time if you're not
prepared for this.
I'm spending a little bit of time explaining the above because I want you to
put on a develoeprs hat and view this problem from a developer's point of
view, not an end user's point of view. Fixing a small problem in one
application is not a big deal, but some companies after they do a software
inventory of access applications discovered they had in excess of 30,000
access applications. hands of small issue becomes a big issue it's a
question scale and size. Only you can answer this for your particular
situation.
I would thus recommend that you use the runtime system for the particlar
version of ms-access your using. However this advice is somewhat tainted
advice, because it's very difficult to get older versions of the runtime.
Microsoft doesn't sell them anymore, as a general rule you can only get the
latest version from them.
By the way you can flip any version of accesss you have to "test" how it
will look on run time. This "swtich" works even when you don't have the
runtime system installed. All you have to do is make a shortcut and add
/runtime switch to the command line.
eg a typical shortcut to access looks like:
"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE"
"c:\program files\RidesXP\RidesXP.mdb"
/wrkgrp "c:\Program Files\RidesXP\Rides.mdw"
/User "RidesAdmin" /pwd "password"
/runtime
(I just added the /runtime swtich to the above. Furthermore note, that that
whole example above what actually be typed on one line of the windows
shortcut you create. if you're not using workgroup security in MS access,
then you're sure cut would likely look like the following:
"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE"
"c:\program files\RidesXP\RidesXP.mdb"
/runtime
Prior to a2007, you had to purchase the runtime devleoper tools. (about $800
dollars).
2 - Unless we buy and learn Visual dot net... or whatever... right?
No you don't have to learn anything new here. The access developer edition,
or so call runtime extensions does not change your development process at
all. The runtime package for MS access is simply a stripped down version of
MS access that has the design tools removed. What this means is that the end
users when they use the runtime system cannot go into form design mode etc.
Thus, the added benefit of using the runtime system is that your end users
thus can NOT modify your applications.
As mentioned, if you want to see what the runtime looks like, try the above
runtime switch on a shortcut to one of your applications.
However there is a few issues that you must be aware of when you use the
runtime system. The most significant issue is that you have to build a
little bit more of your interface, and be more aware of building an
application for the end user. It is assumed that the end user is not really
going to know how to use MS access (in fact the end user does not even have
to know that they're using MS access). Furthermore, the standard acess menus
are hidden. For a lot of people this is also another bonus because they
don't want users to see all that extra access interface junk. However the
downside of this is that hopefully you been writing applications for years
in which the users never did really see the MS access interface, and never
really relied on it. In other words when you deploy using the runtime you
have to provide custom menus, or least a form with menus to launch reports,
forms etc.
For me my applications were hundred percent runtime ready (and I'm talking
about a situation which I never used the runtime). For years I've always
hidden the MS access interface, and I've always built a custom interface for
my users anyway. If you want to see an example an application that would be
runtime ready and has a custom interface than simply download the example
here:
Check out:
http://www.members.shaw.ca/AlbertKallal/msaccess/DownLoad.htm
(Try downloading and running the 3rd example from above).
After you try the application, you can exit, and then re-load the
application, but hold down the shift key to by-pass the start-up options. If
want, you can even disable the shift key by pass. I have a sample mdb file
that will let you "set" the shift key bypass on any application you want.
You can get this at:
http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html
(The shift key bypass features not needed for the runtime, as everything's
always locked out, but since you're gonna be learning to develop and deploy
applications with nice user interfaces I thought I'd share the above with
you).
In the above there was no really special code written to hide the MS access
interface, I simply just use the startup options in MS access and set them
correctly to hide the interface from the user. However the very act of
making the effort to build a custom interface, and also my desire to hide
the access interface means that my application were really very ready to be
deployed in a runtime environment.
Also while we're on this developer topic, you should understand the concept
of a split database.
When you have some time please read the following article, it's another kind
of must know and must understand concept when dealing with MS access from a
developer's point of view.
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
I suppose I should also point out that the runtime can be and is often a
separate installed from your access application. There's no specific tying
or connection between an application you write, and the deployment of the
runtime. Make no mistake here the runtime system is a large install of MS
access, except that certain interface pieces are removed. Once the runtime
is installed on the target system, then clicking on any mdb filewill launch
MS access as it does now. Once the runtime is installed, then you can simply
copy any mdb file to the target computer and it should run (assuming you've
taken into consideration the limitations and issues of the runtime).
So how much work will be for you to use the runtime system? In my case it
takes zero effort and zero work because I always designed applications this
way even before I used the runtime.
So keep in mind that you'll have to make a little bit of effort to provide
you own user interface in your applications, since the runtime system does
not provide the access menus for you.
And I read...
"Access 2007 Developer Extensions and the Access 2007 Runtime will be
available as FREE downloads."
Yes it is available now, and it is free. You can get it here:
http://www.microsoft.com/downloads/...D9-9DC6-4B38-9FA6-2C745A175AED&displaylang=en
So this generates new questions... (and I'm sure I'm late to the party
here)
3 - If we switch to Access 2007 I read that the file extensions change...
so I guess that means we must update every computer in our system... and
convert all our databases... can this be true?
Well I'm not really sure the file extension changes is the big issue here.
However to clarify, you can actually can use the mdb file extension, and
just like for the last twenty years of the computing industry if you stay in
the old format then you'll not be able to use the new features of the next
generation of the software. So you can continue to use the old format. You
have to heed the above advice about all those little problems you worked
around using the current version however.
How much pain will depend on the complexity and amount of code and what you
have now. So, my point here is that it's not really the file extension issue
that you have to worry about, it's just the fact that you're using a
different version (newer) piece of access.
If most of the MDB files are just data, then I would not bother to convert
them out all. However if they are richly developed access applications, then
you've got more of a difficult choice here.
4 - Are these Free downloads available yet?
yes, see link above...
5 - I can 'get by' creating data bases with Access 2003... how is the
learning curve for 2007?
The coding system, and just about everything works exactly the same as the
previous. However things have been moved around, and now instead of using
custom menu bars, you have the ability to create custom ribbons. It's
certainly one of the largest changes in the fifteen years of MS access. I
don't consider it more difficilt, it simply a little bit different. If
you're up to speed on access 2003, then you not have any real difficulty
jumping to a2007. Some people love the new changes in windows Vista. Some of
the old timers don't want anything changed and they insist that they still
want a windows xp box. So, in a way it's kind of asking like is windows
vista a big difficult change, and the answer is no it is not. However for
some people, when few things are moved around, then they don't like it.
I really do love the new interface for access 2007, but I've not yet
deployed and developed any serious applications with it. I suspect that I
will soon try to develop something in access 2007.
