MDB vs MDE for Distribution Question 1

[number2]

I have begun distibution of my db in .mde format. However, I would like to impliment mailing labels in my db. As discussed previously, printer setups CAN NOT be saved in .mde format. It only allows the use of the default printer, or one time use of a specific printer (the user would have to setup the printer EACH time the used the printer in .mde format)

I really need to impliment the mailing label feature. I am leary of distributing in .mdb format due to security and accidental user alteration issues.

However, in order to get mailing label functionality to my db, I am willing to distribute in .mdb format. Is this a mistake? Are there any other reasons why I should avoid distribution in the .mbd format?

 

[VBslammer]

If it were me, I'd go .mde all the way. I also set all my projects to runtime mode to keep users in line.

If you want to control print devices with authority, look at the Access <version> Developer's Handbook Volume 1 by Getz, Litwin and Gilbert. It contains a set of pre-tested class modules that will allow you to control nearly every aspect of printing with a bit of work. Since they've done all the R&D for the included modules, the cost of the book is well worth it.

VBSlammer

 

[number2]

I am a weak programmer at best. Is this something I could tackle? Also, have you had any success in getting an MDE file to save priinter/page setups?

I would love to stay with MDE fformat, however if I can not save printer/page setups, I may need to use the MDB format to gain printer control.

 

[number2]

PS
I am distrinuting in Runtime. How do I restrict the db to runtime only? (in case the user has Access installed)

 

[VBslammer]

Microsoft Knowledge Base Article - Q205151
MOD2000: How to Distribute a Secured Database
The information in this article applies to:
Microsoft Office 2000 Developer
Microsoft Access 2000

This article applies only to a Microsoft Access database (.mdb).

Moderate: Requires basic macro, coding, and interoperability skills.


Summary
When you distribute a secured database as a run-time application, you must take certain precautions to ensure that you can install the application on another computer. This article lists the steps that you should follow to distribute a secured database.
More Information
When you distribute a run-time application to users who have Microsoft Access 2000 on their computers, you should take several precautions to protect the database. To prevent users from making modifications to the objects and code or from inadvertently causing problems with the application, consider these recommendations:
Specify the /runtime switch on all command lines that you use to start the application.
Use the User Level Security Wizard that is provided with Access 2000 to secure all the objects in the database.
Use customized menus and toolbars within the application.
Set the AllowBypassKey property to False to disable the SHIFT key.
Set database Startup properties to prevent users from accessing the Database window and the design of objects.
If the database contains Visual Basic for Applications (VBA) code, compile and save all code, compact the database, and from the results, make an MDE file.
After considering these recommendations, follow these steps to distribute your run-time application:
Open your MDB or MDE file in Access 2000, and enter a user name and a password when you are prompted.
On the Tools menu, point to Macro, and then click Visual Basic Editor.
In the Visual Basic Editor, click Package and Deployment Wizard on the Add-ins menu.

NOTE: If the Package and Deployment Wizard does not appear on the Add-ins menu, click Add-in Manager instead, and in the Add-in Manager dialog box, click the VBA Package and Deployment Wizard, click to select the Loaded/Unloaded and the Load on Startup check boxes, and then click OK.
On the first page of the Package and Deployment Wizard, click Package.
Click Standard Setup Package, and then click Next.
Choose a path to the Package folder, and then click Next.
If you are presented with a Missing Dependency Information dialog box, handle appropriately, and then click OK.
Click to select the Include Access Runtime check box, and then provide access to the ODETools\V9\Runtime folder.
Click Add, and in the Add File dialog box, click All Files (*.*) in the Files of type list. Browse to the folder that contains the secured .mdw file, select the file, click Open, and then click Next.
Enter an Installation title, a command to run (if you want), and then click Next.
Determine your startup menu group and item. Click to highlight the item, and then click Properties. Note the Target property similar to the following, where <dbname> is the actual name of your database:
&quot;$(AppPath)\<dbname>.mdb&quot;
Change this property as follows, replacing <securedfile> with the actual name of your secured workgroup file and replacing <dbname> with the actual name of your database. Then, click OK and Next.
/wrkgrp &quot;$(AppPath)\<securedfile>.mdw&quot; &quot;$(AppPath)\<dbname>.mdb&quot;
Modify any Install Locations if you want, and then click Next.

NOTE: If you change the Install Location for your secured workgroup file, make sure you go back and change the Target property as described in the preceding step.
Click to select the files that you want to install as shared files, and then click Next.
Enter a script name, and then click Finish.
After the package is created, save the packaging report if you want, and then click Close.
Click Close again, close the Visual Basic Editor, and then quit Microsoft Access.
Share your Package folder or copy the folder to a compact disc (CD).
On a clean Microsoft Windows-based computer (a computer that does not have Microsoft Access installed), install the run-time application from the shared Package folder or CD.
After it is installed, start the application. If the application is installed correctly, the user should be prompted to first enter a name and a password before the application opens. If this does not occur, make sure that the run-time application is pointing to the secured MDW file. To do this, follow these steps:
Start the Workgroup Administrator (Wrkgadm.exe) utility.
Click Join, and then join to the secured MDW file.
Quit the Workgroup Administrator, and then restart the run-time application.
References
For additional information about distributing the Workgroup Administrator with your Access run-time, click the article number below to view the article in the Microsoft Knowledge Base:
Q241479 MOD2000: Package and Deployment Wizard Does Not Have Option to Include the Workgroup Information File

For additional information about distributing an Access project, click the article number below to view the article in the Microsoft Knowledge Base:
Q240293 MOD2000: How to Deploy an Access Data Project That Includes the Microsoft Data Engine

For additional information about securing an Access database, click the article numbers below to view the articles in the Microsoft Knowledge Base:
Q254372 ACC2000: Overview of How to Secure a Microsoft Access Database
VBSlammer

 

[number2]

ouch. While I am aware of and have used several of the primary suggestions, the last several paragraphs are way over my head. Some issues I have run into include:

toolbar/menu changes from machine to machine (my &quot;custom menus&quot; do not carry over from machine to machine)

Password difficulty.

I have the application working and it installs well. I am really afraid of making changes at this point which will ruin my application.

I was distributing iin .MDE format, but I neen printer /page saving in order to get a mailing label function. If the only way to do this is to distribute in .MDB format, then I must use the .MDB format.

Are there any other reasons (other than security) why I should not distribute in .MDB format?

PS. the biggest security/piracy problem is copying of the distribution CDROM, not code stealing.

 

[VBslammer]

You can lock down an mdb to a point that's close to a runtime app. Stan Leszynski calls this &quot;Bulletproofing&quot; the application, whereby all the standard menus and toolbars are replaced, the startup options are all set to remove user access to design modes, the database window, etc., and an Autokeys macro is in place to intercept keyboard shortcuts.

Most heavy-duty apps that need runtime reporting features ultimately resort to a 3rd party add-in like &quot;Crystal Reports.&quot;

Another way to handle labels would be to automate Word and do a mailmerge type operation with data from your database. With Word you could let your users print any way they want.
VBSlammer

 

[gusbrunston]

Dear VBslammer:
The star's from me. Thanks.
Gus Brunston An old PICKer, using Access2000. I manage

http://www.rentdex.com.

Suggestions welcome. padregus@attbi.com

 

[number2]

Locking down the MDB sounds promising. Is that something which is easily done? From the discription above it sounds quite complicated. Maybe I need to find a consultant to do this for me?