Using the Access 2007 run-time with a split database

[Philip Herlihy]

A friend is developing a database for a medical charity, so needs to
keep costs down. We've been wondering to what extent we can use the
free Access 2007 runtime to reduce licensing costs for Access. I
understand (although I've never tried it) that a database which is a
self-contained application can be installed with only the run-time
present on the target machine, but how does this work if you want to
maintain a back-end database on a separate machine? Or will we need a
full Access license?

Phil, London

 

[Douglas J. Steele]

You don't actually need Access at all in order to have a back-end database
on a separate machine.

You'll obviously need at least one copy of Access in order to be able to
design and build the application, but that's it (and that copy does not have
to be present in the office where the database is being used)

 

[NG]

Hi,

you can ship the app with the runtime version, but take care that you design
a window that allows to handle the links because the regular Access menu's
and ribbons are not available in the runtime version. You can try it out on
your machine by creating a shortcut on your desktop and add the option
/runtime in the target line. This forces the app to open with the runtime
version. More info you can find on
http://msdn.microsoft.com/en-us/library/bb501030.aspx

 

[Philip Herlihy]

You don't actually need Access at all in order to have a back-end database
on a separate machine.

You'll obviously need at least one copy of Access in order to be able to
design and build the application, but that's it (and that copy does not have
to be present in the office where the database is being used)

Thanks Douglas!

Phil

 

[Philip Herlihy]

Hi,

you can ship the app with the runtime version, but take care that you design
a window that allows to handle the links because the regular Access menu's
and ribbons are not available in the runtime version. You can try it out on
your machine by creating a shortcut on your desktop and add the option
/runtime in the target line. This forces the app to open with the runtime
version. More info you can find on
http://msdn.microsoft.com/en-us/library/bb501030.aspx

Thanks Noella! Obviously I need to look into this carefully - thanks
for the link. Before I've studied it I'm wondering if it will be
sufficient to hard-code the front-end to look for a specific share on
the "server"? I'm also wondering if the runtime is needed at all on the
server - I can envisage alternative architectures where interaction to
the back-end file is mediated by an Access process, or where all the
front-end needs is access to the containing folder, doing file
operations (like creating the .ldb file) itself. Now I need to find a
machine without Access installed to test it out!

Best wishes,

Phil

 

[Philip Herlihy]

Thanks Noella! Obviously I need to look into this carefully - thanks
for the link. Before I've studied it I'm wondering if it will be
sufficient to hard-code the front-end to look for a specific share on
the "server"? I'm also wondering if the runtime is needed at all on the
server - I can envisage alternative architectures where interaction to
the back-end file is mediated by an Access process, or where all the
front-end needs is access to the containing folder, doing file
operations (like creating the .ldb file) itself. Now I need to find a
machine without Access installed to test it out!

Best wishes,

Phil

Just to report the test result - I found a machine without any version
of Access installed. Copied a database and split it. Moved the
back-end to a share on the test machine, and re-linked. Worked
perfectly. This shows that there is no need for any sort of Access
runtime on a back-end machine. I guess it needn't even be a Windows
machine, if sharing is appropriately set up (e.g. Samba).

Phil