restrict design access

  • Thread starter Thread starter Del J
  • Start date Start date
That looks good but my management is notorious for requesting expansions,
etc. Because of difficulties reconciling data between the mde file & saved
copy of the database this looks like it would work best as a
front-end/back-end database. The problem here is that I have no experience
with front-end/back-end databases.

Is there another way to prevent users from accessing form design?
 
Keeping the workable MDB and executable MDE is actually very easy. When you
have the MDB at the next distributable version, simply make a copy and
convert the copy to an MDE, and continue updates with the MDB until you're
ready for the next distribution.

In fact, if you do have multiple users, you can automate the update process
using Tony's AutoFE Updater (a very helpful peice of work for those of us on
the lazy side).

http://www.granite.ab.ca/access/autofe.htm


And I would definately recommend splitting the database, even if there's
only one copy being run and it's not on a true multiuser setup. Splitting
the db has many advantages even for the single user, updates without
compromising your data being one of them. Again, this is suprisingly easy
and takes about 5 seconds by your second of third time around.


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)
 
Ok, I'll give this FE/BE structure a try. I'm self-taught with gaps in my
understanding of the whole. Here are some questions I can think of right
now. Is there anything else I might need to know?

A. Is it as simple as having 2 databases with the tables in the BE &
everything else in the FE?

B. It will be a multi-user environment. As I understand it the BE will be
on the server & multiple copies of the FE distributed to the various user's
computer

C. What is the best way to link my tables to the FE?

D. Right now I have the following references enabled. What else will I
need to enable?
* VB for Apps
* MS Access 9.0 Object Lib
* OLE Auto
* MS ActiveX Data Objects 2.1 Lib

Thanks for all the help
 
A. Is it as simple as having 2 databases with the tables in the BE &
everything else in the FE?
Yup


B. It will be a multi-user environment. As I understand it the BE will be
on the server & multiple copies of the FE distributed to the various user's
computer
Yup


C. What is the best way to link my tables to the FE?
Click to expand...

When you split the db, access will take care of this for you (if you use the
wizard). However, if you change the location of the BE after you split, you
will need to update it on the frontend (using the linked table manager). Or,
see this code to programatically relink on startup (a bit more advanced...)

http://www.mvps.org/access/tables/tbl0009.htm

If by chance you do take this route, only run this code if the tables are
not already linked, rather than on each startup (relinking every time it
starts causes 'bloat').

Your best bet here is to use the server path in the MDB with the linked
table manager, then you can deploy it to any computer on the network without
having to screw with it (the server path should be the same for every client
computer... \\Server\Folder\File.mdb... avoid mapped drives at all costs).


D. Right now I have the following references enabled. What else will I
need to enable?
* VB for Apps
* MS Access 9.0 Object Lib
* OLE Auto
* MS ActiveX Data Objects 2.1 Lib
Click to expand...

Nothing.

References play no part in splitting a database... whatever you currently
require will not change (expect maybe with the code to programmatically
relink... if I remember correctly this may require DAO3.6 (or ACE(?) for
'07). But you probably won't use this right off the bat anyway.

hth

--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
 
I suppose it's a matter of preference, but I personally start off with two
blanks and build like that, rather than splitting later on. It's a little
bit more of a pain when you have to update the BE tables (can't do it from
the FE), but it's nice to work in more of an "actual environment" setup,
especially if you're going to have any local tables or the like... you won't
have to worry about testing everything one last time after you're done with
everything and then split it.


--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)
 
Back
Top