Jim Dettman
jimdettman at verizon.net
Mon Aug 9 09:28:42 CDT 2010
Brad, I think the only thing I would add is: 1. A backup of the new changed ACCDB file before attempting a decompile. Folks need to remember that while decompile does work 99.9% of the time, it still is an undocumented and untested switch by Microsoft. If rare cases, it can mess up a DB. 2. I generally make an archive copy of the existing production database before copying over it. That why, if there is some form of corruption in new DB, I have a "Last known good copy" to fall back on. Also, not sure how your handling versioning, but I keep a local table in the db, tblAppVersionControl, which has the version number, developer notes, end user message, and release date. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks Sent: Monday, August 09, 2010 10:19 AM To: accessd at databaseadvisors.com Subject: [AccessD] "Test to Production" Procedures for Access 2007 application in a small environment All, I am in the process of establishing procedures for promoting changes from our Development (TEST) environment to our Production environment. The Access 2007 application uses data from a SQL Server database. There are no local tables. The application is made available to the end-users as an .ACCDR file. I have one folder on the server for TEST and a second folder for PROD. Here the steps that I am currently using. Changes to the Access 2007 application are made and tested in the TEST folder (ACCDB file). Decompile ACCDB Compile ACCDB VBA code / Save it Compact and Repair ACCDB / Save it Run a Utility to Copy the ACCDB file in the TEST folder to the ACCDR file in the PROD folder. I am curious if these steps are similar to the steps that others use and I am curious if I am overlooking anything. Thanks, Brad -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com