Chris said:
You're right I am not clear on what the runtime is. Can I create a db
in the developer version with it's table forms and query create a
runtime burn it to CD and give to a user to use (perform queries
etc). I was sort of concerned that the runtime is like when you split
a db into a front end and backend. The frontend has to be sitting
somewhere accessible to backend. I was concerned it might be just be
the front end.
When you install the Runtime you are in fact installing Access. It is the
very same program (and just as large) as if the user went out and purchased
Access. The Runtime just has a LOT of registry entries that disable
development (and a few features as stated in previous post). This results
in an instance of Access that can "run" Access apps, but not be used to
create or modify them (design wise).
Your app is not modified in any way when you create a runtime deployment
package. It is the same MDB/MDE that you have now and it can be either
split or unsplit as you see fit.
However; an Access app has to be "appropriately designed" to be usable in
the runtime environment. There is none of the normal Access user interface
exposed in the runtime (no db window, no menus, no toolbars, etc.). You
have to build all of these yourself in the application before deploying it.
The app must also have must more robust error handling because the normal
"Access provided" error handling is mostly absent. Unhandled errors in the
runtime will more often than not terminate the program and it will have to
be restarted.