Locking the design view of a form

[mykil]

Is their a way to lock the design view of the FORM? This is to avoid the Future users accidentally open or change the design...Thus anybody knows how to do it? If so, Please Help


Your Help will be much appreciated

 

[GinaWhipp]

The only thought that comes to mind is to ditribute an .MDE (.ACCDE) in which no design changes can be made. This should be done on a split database so you can update the Front End should you make any changes.

 

[missinglinq]

Depending on your version of Access, simply convert your MDB or ACCDB file to a MDE or ACCDE file format before distributing to the end users. No Design Views/Tools will be available to them.

WARNING! Before converting your original file, make at least one copy of your MDB or ACCDB and store it in a safe place. This will give you two copies, including the original, after the conversion. You will need a copy of the original MDB or ACCDB file anytime you need to modify the app. You can make no changes to the MDE or ACCDE files, which is the entire point, of course!

After copying the original file to a safe place, do a Compile as well as a Compact & Repair. In Design View, on versions 2003 or earlier, you'd go to Tools - Database Utilities - Make MDE File.

I don't run later versions, so if you do you'll need to use Help to locate the Database Utilities.

Linq ;0)>

 

[mykil]

Thanks to Both of You... I'd tried it and it's pretty cool working... I'm working with ms access 2007 and I've converted my project from ACCDB to ACCDE as what you've both said and have a back up of the original file.. But, what if I Want to edit the Design of the ACCDE forms, is it also possible or Do I need to replace it with the original ACCDB forms...

 

[GinaWhipp]

That is why I suggested splitting. When you make Design changes you make a copy, turn the updated front end to an .ACCDE and ditribute!

 

[tobyjenkins]

I'm in a similar position - I have created a database, looks great work nice then I split it so multiple users can access it and still allow me to debug etc. in the background. I have merged the files together again because the split DB was soo slow over our network.

WHat I do is keep a "master copy of the MDB file in a hidden folder while people make use of the compacted MDE file. This allows me to have a carbon copy (apart from record updates) that I can work on and fix. Once it's working I then wait until there's nobody using the MDE file, lock it and import the tables from it into the master version, which I can then me compile and MDE. This then replaces the old MDE version and we're good to go, having lost only one or two minutes of actually database downtime.

Does that make any sense? Sorry if not - it's been a long day...

 

[missinglinq]

Running a multi-user database without having it split, and each user having a copy of the front end on their machine, is a tried and true method of creating all kinds of problems, including timing problems (with some or all users locked out of tables and unable to work) and major data corruption/loss!

Unfortunately, the fact that some users have had multi-user, non-split DBs running successfully for some time is totally meaningless! I've seen reports of such apps running smoothly for as long as 14 years and then bombing out! And once trouble starts it never stops! All it apparently takes is some combination of events to occur and BOOM!

It's not a question of will the database become corrupt, but rather of when it will become corrupt! And as I said, once this type of corruption starts it will occur over and over and over again, until the app is split!

Unless you can afford major data loss and repeated episodes of down time, while you try to patch things back together, you need to split your app again and then find out why it is running so slow on your network.

Linq ;0)>

 

[tobyjenkins]

Absolutely agree but in my case, our network was causing mahassive bottlenecks (they were even worse when people tried to access through remote access) and the whole thing became unusable. In an ideal world I would have create a PHP front-end but that wasn't an option. I guess sometimes you just have to swallow the poison. Or poisson. Not sure which.

Did lots of testing with locally stored FE and BE, local FE, shared BE, and so on and so forth.. only when it was in the environment where it was going to be usable my the various people needing access was it depressingly slow... I'm no expert and would certainly rather a split but it's not workable because of our Council's hardware (it's slow with everything).

Where's that vile gone..?

 

[mykil]

That is why I suggested splitting. When you make Design changes you make a copy, turn the updated front end to an .ACCDE and ditribute!

Yes, I already split my database and Produce an ACCDE. But only the Tables which in the BACK END is only editable.. I Couldn't Edit the DESIGN FORM of my FORMS....

 

[Galaxiom]

Yes, I already split my database and Produce an ACCDE. But only the Tables which in the BACK END is only editable.. I Couldn't Edit the DESIGN FORM of my FORMS....

Yes that is exactly what has been described. The ACCDE is an executable that cannot be edited. That is the whole point of the executable version.

As repeatedly emphasised you need to keep a copy of the ACCDB version of the Front End for further editing. Once the changes have been made in the ACCDB you create a new ACCDE and distribute that.

 

[GinaWhipp]

Thank you Galaxiom!

For all those dealing with speed issues, see...

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

Speed up Database…
http://www.blueclaw-db.com/access_consultant_rapid.htm

FYI, I have databases that are accessed by many with no speed issues.

 

[mykil]

Ah.. Okay, Now I Understand.. Thanks to all of you for Helping me...It really solves my problem..

 

[mykil]

Yes that is exactly what has been described. The ACCDE is an executable that cannot be edited. That is the whole point of the executable version.

As repeatedly emphasised you need to keep a copy of the ACCDB version of the Front End for further editing. Once the changes have been made in the ACCDB you create a new ACCDE and distribute that.

Thanks for the help for making me understand the subject matter clearly..




Mykil

 

[Coco50]

Hello,

I splitted my database but, when attempting to convert my frontend to an MDE file I received the following error message below;

This error is usually associated with compiling a large database into an MDE file.　 Due to the method used to compile the database, a considerable number of TableID references are created for each table.　 The Microsoft Jet database engine version 4.0 can only create a maximum of 2048 open TableIDs at one time.　 Exporting a database as an MDE potentially can exceed this limit if the database has a large number of objects (table, macro, form, report, etc).

Are there any other options to proctect my design view?