Results 1 to 6 of 6
  1. #1
    rjgriffin46 is offline Competent Performer
    Windows 7 32bit Access 2010 32bit
    Join Date
    Apr 2014
    Location
    New Jersey
    Posts
    118

    Putting Production Table Changes into Production


    I may have posed this question before but I could not find an answer in my previous posts.

    What are best practices or suggestions for the best way to update production tables for which you've made changes in development (eg., adding fields being the most common, changing a list lookup field to reference a table)?

    To date I have viewed my production and development tables side by side and edited the production table design while no one is using the database. I'd thought copying the development table and pasting with the Structure Only option might apply the new design without changing any data but this just creates an empty table.

    Any thoughts or references would be appreciated.

    Thanks

  2. #2
    Perceptus's Avatar
    Perceptus is offline Expert
    Windows 7 64bit Access 2007
    Join Date
    Nov 2012
    Location
    Knoxville, Tennessee
    Posts
    659
    How I do it.

    I have administrative access to all pc's that use the database. I also have all the current database front ends stored in a mapped network drive. I copy these front ends to my Development PC and update them as needed. When im satisfied that an update is needed. I copy this worked on front end to the mapped network drive. Then I use Admin Script Editors Script Deploy along with a Windows Script File that is located on each Users PC. The script file allows me to have each machine copy over the new front ends as well as kill any currently open access sessions if they are open. When I run the Script Deploy, i pass Job Parameters to the WSF file. which looks like this

    Cscript C:\PDS\update.wsf //H:Wscript //Job:Sales //Job:Shipping

    This updates the Sales and Shipping databases for all PC's that I have selected in Script Deploy.

    I have update.wsf set to use wscript.echo along with creating an Update log on each users PC's.
    Patience serves as a protection against wrongs as clothes do against cold.

  3. #3
    rjgriffin46 is offline Competent Performer
    Windows 7 32bit Access 2010 32bit
    Join Date
    Apr 2014
    Location
    New Jersey
    Posts
    118

    Putting (Back end) Table Design Changes into Production

    Quote Originally Posted by Perceptus View Post
    How I do it.

    I have administrative access to all pc's that use the database. I also have all the current database front ends stored in a mapped network drive. I copy these front ends to my Development PC and update them as needed. When im satisfied that an update is needed. I copy this worked on front end to the mapped network drive. Then I use Admin Script Editors Script Deploy along with a Windows Script File that is located on each Users PC. The script file allows me to have each machine copy over the new front ends as well as kill any currently open access sessions if they are open. When I run the Script Deploy, i pass Job Parameters to the WSF file. which looks like this

    Cscript C:\PDS\update.wsf //H:Wscript //Job:Sales //Job:Shipping

    This updates the Sales and Shipping databases for all PC's that I have selected in Script Deploy.

    I have update.wsf set to use wscript.echo along with creating an Update log on each users PC's.
    Thanks for this information. I was, however, specifically referring to (back end) table design changes (eg., adding and/or changing fields in existing production tables). Your information seems only to apply to front ends.

  4. #4
    Perceptus's Avatar
    Perceptus is offline Expert
    Windows 7 64bit Access 2007
    Join Date
    Nov 2012
    Location
    Knoxville, Tennessee
    Posts
    659
    Ah You seek Yoda!
    ...

    You are looking for database normalization suggestions?

    For changing a field. I generally close all open file handles on the Backend. and update as needed within the Access UI. Very rarely do I use sql to Alter Table statements. I avoid making any new field required in a table that isnt new.

    Sounds like you want to Import a table into your live database using the import function. Choosing to Import Data and Structure.
    Patience serves as a protection against wrongs as clothes do against cold.

  5. #5
    ItsMe's Avatar
    ItsMe is offline Sometimes Helpful
    Windows 8 Access 2013
    Join Date
    Aug 2013
    Posts
    7,863
    I use a paper notepad, an ERD, Text File, and Excel. The ERD does the high level stuff. The pen and paper tracks things that went wrong and need to be fixed. The spreadsheet lists objects that have been edited. And the text file documents the details of permanent changes.

    I have been enjoying Lucid Chart, lately.
    https://www.lucidchart.com/

  6. #6
    rjgriffin46 is offline Competent Performer
    Windows 7 32bit Access 2010 32bit
    Join Date
    Apr 2014
    Location
    New Jersey
    Posts
    118
    I have found Total Database Detective from FMS to be useful in identifying new tables, fields and field properties in the development back end that are not in the production back end. I use this software to compare my production and development back end Access files to tell me what needs to be done to the production back end. This has proved invaluable, greatly reducing the likelihood of missing a back end change. Note: it presently does not address data macros but FMS is supposedly evaluating adding this in the future.

    But I don't know of any automated way of implementing these back end table changes. Fortunately the application isn't that frequently used, so when I am making back end changes I can advise the users and then put the back end in Read Only mode via file Properties, Attributes while I make the changes to a copy of the production back end and test with the new front end. Once satisfied, I then replace the users front end with the new front end that is linked to the new back end. I re-use an implementation check list table in a Word document to check off all the steps.

    I'm going to close this Thread, but if anyone has any additional thoughts I'd appreciate hearing them.

Please reply to this thread with any new information or opinions.

Similar Threads

  1. production records
    By adriana in forum SQL Server
    Replies: 3
    Last Post: 05-11-2013, 11:16 AM
  2. Need a form to relieve a production log
    By payton_fulton in forum Forms
    Replies: 15
    Last Post: 05-11-2012, 03:31 AM
  3. Track Production using linked table from QODBC
    By flwrgrl in forum Database Design
    Replies: 9
    Last Post: 05-25-2011, 01:25 PM
  4. Production Tracking
    By old_chopper in forum Access
    Replies: 2
    Last Post: 10-11-2010, 12:12 PM
  5. Production
    By teranet in forum Access
    Replies: 1
    Last Post: 06-07-2008, 06:47 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums - Senior Forums