Re: Splitting Database - multiuser

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Yes, that's right.

In a small setting, you just copy the new MDE to each workstation.

For an automated process, see Tony Toews solution:
http://www.granite.ab.ca/access/autofe.htm

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

"Mcrawford" <Mcrawford@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:FBA8885B-7DC4-4879-9A1D-69C10A6BB0A1@xxxxxxxxxxxxxxxx
Allen, If I choose to use MDE files what is the best practice for updating
when I make changes?

I'm assuming I make changes to a "master" MDB front end file and then
re-make MDE files each time I have an update, is this correct?

"Allen Browne" wrote:

The important thing is that each user opens a separate MDB/E file. Ideally
it's on their local hard disk, since that's faster than the network and
reduces the network traffic, but you can use separate files on the server
(e.g. in the user's workspace) if necessary.

You can create an MDE using Access:
Tools | Database Utilities | Make MDE

The user cannot mess up your forms, reports, or code if you give them an
MDE. An MDB is fine if you trust them not to fiddle, if you want them to be
able to create/modify their own forms/reports/code and change yours, and if
they all use the same version of Access (to avoid the faulty binary problems
that occur when switching versions.)

"Mcrawford" <Mcrawford@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5244BF3E-D955-4653-8608-FBEA722C0F20@xxxxxxxxxxxxxxxx
>I have split my database. I have four users that will be using the front
>end.
> I've read that each user should have the front end on their local > systems.
> What are the disadvantages of having the front end on a shared network
> drive
> so that all four users can access a single front end (instead of having > it
> on
> each pc).
>
> Also, when I split the database the original name was TSCL.mdb. It > split
> into TSCL_be.mdb (back end) and TSCL.mdb (front end). I've seen some
> postings
> about the front ending being a .mde file...why is mine a mdb file? Do I
> need
> to do some sort of conversion to make it an mde file, if so, why?
>
> I'll continue to search for reasons for using mde file, but thought I
> would
> see what you all have to say.

.

Relevant Pages

  • Re: Acces VBA Password
    ... > the product, the Make MDE file selection is not enabled on the Tools, ... Web page to help you determine why you can't create the MDE database: ... version of the VBA source code, even if there's a VBA password placed on the ...
    (microsoft.public.access.security)
  • Re: MDE and extracting data
    ... you split your database in a Front End (everything but the data ... and import all the tables from the working copy of the .mde (so you ... .mdb with the latest design and up-to-date data. ... > the MDE file has been used successfully, ...
    (microsoft.public.access.externaldata)
  • Re: Creating MDEs
    ... There may be coding errors in your database. ... Then try making an MDE file from the ... ACC2002: Error Message: "Microsoft Access Was Unable to Create an MDE Database" ...
    (microsoft.public.access.forms)
  • Re: MDE Problem
    ... within the mde. ... The implication of what you say seems to be that the MDE file has been ... entered (in an event property), Access is raising the event and is trying ... run either a macro, user-defined function, or event procedure - but it ...
    (microsoft.public.access.setupconfig)
  • Re: File size the same after major deletions
    ... I see where you deleted stuff and the MDE was still the same size. ... What I didn't see was any reference to a compact and repair on the MDB ... I had a database over 300Mb that I tried to ... >> It's set up with an .mde file that is used as the User ...
    (microsoft.public.access.gettingstarted)