|
|  |
|
|
Making Changes to your Application
by Barry Rochford
Untitled
I saw an interesting Message on the Alpha Message Board the other day:
Subject: Upgrade Application Process
What is the proper way to make changes to an application?
"From this point on, I will use a laptop to make changes to our office application, maybe once or twice a week, until I have it the way I want it. After making changes, I will need to upgrade the application on the server."
The message had 2 replies both answering the question of the files to be included. I thought that many new users who have varying degrees of experience & background might be interested in some additional comments and techniques. I borrowed some techniques from my Mainframe Programming & Systems Analyst days (back in the olden days). Those techniques worked then and they still work now.
1. Each application has a one record table used for all menu/startup forms. This table always has a field named "Version" it is a char. field length of 20. It normally starts with "Version 1 Build 01". Every time I distribute changes to an application the build number is incremented by 1.
2. I display the Version / Build Number on the Main Menu. There's no question about what Build is installed. Follow the Red Arrow on the Screen Shot below.
3. When I am starting to make changes/corrections to an Application I print out a Blank "Build Sheet" I staple it to the front of the application folder (that keeps me from "misplacing" it).
As I make changes, I record the Table/Set Name, short change description, what files are to be sent and time spent (for billing purposes).
When the changes are all complete and I'm ready to distribute the new Build, I then must also change the Build Number in the "Start.dbf". I also transcribe the handwritten Build sheet and make a final copy (using as File Name the Client Name followed by "Build" & the Build Number). The copy is filed in the Customers File Folder and e-mailed to the Client along with the Zip File containing the changes.
That helps me to make certain I recorded every change and I am going to send the correct files. The Client is e-mailed a copy of the Build Sheet (Client copy includes only total hours, error corrections are gratis).
You might say that's too much work - I don't need all that. Well, it's an excellent Audit Trail, and provides great documentation which can prevent a lot of errors & omissions. When a Client asks, when did you change such and such or asks for an explanation of your Charges, you have copies of each Build Sheet and you can see exactly when you made the change, hours involved & the name of the zip file (Lennons25.zip in the example).
Now, where should you keep all these files? I'm glad you asked! On my Desktop I have a Folder named "C:\ALPHA_DATA". It contains folders for each of my Applications.
Assume I have an Application in a Folder named "C:\ALPHA_DATA\Lennons" and I need to make some changes. You should make it a rule to NEVER make changes to the programs and coding installed at the Customer's place of business! I make a new Folder named "C:\ALPHA_DATA\Lennons_DEV", copy the contents of the "Lennons" Folder into the new "Lennons_DEV" Folder, now I develop all changes in the Development folder which is a lot safer that using your primary copy of the Application. No one ever got fired for having too much Back-up & you can never be too careful!
Just prior to e-mailing the ZIP File with the new changes, I perform one final test. I unzip the ZIP File into my Primary Folder for that Client ("C:\Alpha_Data\Lennons" in this example). I then check out the changes just to make certain that nothing has been overlooked, such as forgetting to include a file. (Remember, I do have their primary folder backed up in case there is a problem.)
I also have a Folder named "C:\ALPHA_ OTHER". It also contains a folder for each Application ("C:\ALPHA_OTHER\Lennons_Build", "C:\ALPHA_OTHER\SAQ_Build", for example). Every zip file sent to a Client is saved in their respective Folder in the ALPHA_OTHER Folder. Remember also, all of the Zip Files include the Build Number ("Lennons25.zip", "Lennons26.zip" "SAQ18.zip", etc.).
Using these techniques won't make you perfect, but if all this Article does is give you an idea or two, then it has been worth-while.
Barry is an Alpha Developer living between New Hope & Newtown in Pennsylvania. The area is also unique in having 3 Alpha Developers within a 5 mile radius. Could it be the PCB's in the water? Or that Toxic Waste Site just up the road? Hmmm....
[PRINTER FRIENDLY VERSION]
|
|
|
