By Barry Rochford
In distributing your Application there are several scenarios. The list below shows each of them:
I have a folder Named "ALPHA_DATA". It contains folders for each of my Applications. I do all Development in ALPHA_DATA.
I also have a folder named APPLICATIONS". It contains folders for each finished Application. All tables are "empty", with the exception of those used for "lookups" & Licensing Information etc. If its a Lookup table, it contains data. Each of my Applications contains a "START" table, usually containing 1 empty record.
For a "New" customer you could zip up the entire c:\Applications\My_Application and send it out (with complete installation instructions included). I do have an Application that I wrote for a Client, they in turn re-sell & install it to their Clients. For a situation like that I handle it just a little differently. I separate all of the tables and zip them up to a Blankdbf.zip file. Then when I send my client a new Release, it will not overwrite his test data.
Well, youve done it! Finally completed your Delivery Scheduling Application which you have appropriately named "DSAandAway". Using 5 lines of Xbasic coding you have elegantly solved the infamous "Salesman Problem" (A Salesman must visit 10 widely scattered customers in the least amount of total miles driven). Of course, your first Client has been running it for over 2 weeks now, the results are amazing, reducing delivery cost up to 79%! After your Client returned from the Delivery & Freight Forwarders National Convention, extolling "DSA & Away", your Fax machine ground out requests for Pricing Information by the dozens, the phone calls came, your mailbox is overflowing with the Orders and checks rolling in.
You are overjoyed, when suddenly, reality sets in, along with that familiar queasy, tight feeling in your tummy. How are you going to ship "DSA & Away" to your Customers? The good news is, when Zipped, it will all fit nicely on a 3.5 inch floppy diskette. This is a very tight Application, you have only 6 Tables, 2 Sets and, of course, 1 Database (DSAandAway).
Here are the Tables and Sets:
Start table Has only 1 record, contains Client Name, their License number and Version Number
Delivery_Master table
Delivery_Stop table
Truck table
Gl_tran table
GVW_lookup table Contains the ICC standard Gross Vehicle Weights for use in your calculations
Delivery Set
GL set
Your Desktop PC has everything including your test data in c:\Alpha_Data\DSA. Looking in the Appendix of your Alpha Manual for the first time, you discover all the Alpha Five Files are described. Looks easy, you just copy everything onto a diskette and send it out. Whoops, you dont want to be sending out your test data, but you need to keep it.
Better make up a little list showing what needs to be done to each table before sending out "DSAandAway" to a new User.
| TABLE NAME |
CONTENTS FOR NEW INSTALLATION |
| Start |
Must contain ONLY 1 BLANK record |
| Delivery_Master |
Must be BLANK, no records |
Delivery_Stop |
Must be BLANK, no records |
Truck |
Must be BLANK, no records |
GL_tran |
Must be BLANK, no records |
GVW_lookup |
Contains DATA |
Ok, you create a new folder, c:\Applications\DSA_App and copy c:\Alpha_Data\DSA into the new folder. Then start Alpha Five, select the new Folder, select DSAandAway. From the control panel, select tables & sets, R-Click each table that is listed as "Must be blank", select "Empty the Table". Almost done, lets handle Start Table which must have 1 blank record in it. From the Control Panel, DBL-click it and remove the contents of each field, click on SAVE and we are almost there. The GVW_lookup is fine, it has data and is all set to go as is. Now we have 2 copies of "DSAandAway", the Development Copy and the Master Copy.
I sometimes create a separate ZIP File called "EMPTYdbf.zip". Compress all the .dbf & .cdx (and .fpt if any) files into EMPTYdbf.zip". Its now ready to go and it includes the data, indexes and memo fields (if any) for all tables used by your application.
Next, create another ZIP File called "DSA.zip" Compress all the following:
DSAandAway.ADB, .ALB, .ALM & .ALX (this is your Database)
All .DDD, .DDM & .DDX files (1 set of three for each Table)
All .SET, .SEM & .SEX files (1 set of three for each set)
You now have 2 ZIP files. When you receive a new Order for "DSAandAway", you send both ZIP Files, dont forget to include your step-by-step Installation instructions., including using a full version of Alpha Five or the Run-time Version.
Leaving your Mother-in-law in charge, you and your Wife are off to St. Martin (in case you havent been there, its in the Lesser Antilles). In the middle of your 5th Week on the French Side of St. Martin, you receive a frantic call. Guess who? Its your Mother-in-law telling you that a bug has been discovered in "DSAandAway". The Report showing how much has been saved by using your Application is now showing ERROR instead of a Dollar Amount. You grab your Laptop, check it out and sure enough, you set up the "Total Amount Saved YTD" print field for $99,999.99. A simple error, fortunately the field itself is N 12.2. Who would have ever thought it would exceed that, better increase your price! You make the Report field change using $9,999,999,999.99 as the size, save the report and youre finished. Yes, but how do you get the change to your Clients, now numbering in the hundreds?
You look and see the Report is attached to the "Delivery_Master" table. Looking in your Alpha Five Manual, you see that Layouts are saved in a tables .DDD, .DDM & .DDX files. If the Report had been attached to a SET, the layouts would be saved in the Sets .SET, .SEM & .SEX files. First, make certain the change works, next copy the Delivery_Master.DDD, .DDM & .DDX files to c:\DSA_App (this updates the Master Copy of the Application), finally, send just the Delivery_Master.DDD, .DDM. & .DDX files to each User (including update instructions). Finally, you Email the files and instructions to "Mom".
Well, back to the Beach. Just days later though, another call from "Mom." This time the EPA is involved. Due to the sharp decrease in Gasoline & Diesel fuel consumption by "DSAandAway" users, the EPA wants timely Environmental Impact Statements. Failure to comply will result in the incarceration of your Mother-in-law. As attractive as that may sound, you do decide to look at what needs to be done.
You discover that its not going to be difficult to furnish the information required by the EPA. You create a new table, "EPA_Info", set up 1 additional report based on that table and you are done. Ok, you can just send your Users the new empty "EPA_Info" .dbf, .cdx, .ddd, .ddm & .ddx files right? Wrong, your new table will not be attached to the Database. You must also include the DSAandAway.ADB, .ALB, .ALM & .ALX files. Of course you must update your Master Copy. Dont forget to add the empty "EPA_Info".dbf, .cdx & .fpt files to your "EMPTYdbf.zip" file. Remember the Cardinal Rule, never send a .DBF .CDX or .FPT file to an existing user unless you are adding a table to the database. You can easily WIPE OUT their live data files!
The phone rings, its "Mom" again, now the IRS Enforcement Division is requiring that you include another calculation on the Report of Savings YTD. "Mom" is very concerned that her innocuous mistake of getting SSNs for her three cats and listing them as dependents will come to light. Well, what a decision to have to make this early in the morning. You do decide to honor the IRS request. Great, you discover that adding 1 field to the "Delivery_Master" table will take care of what is needed. You test it very carefully, it works in all cases. Now, how to get this added field out to your customers?
This is a serious problem! Easy enough to do from the Control Panel, but your customers dont have access to the Control Panel. How can you get this change to your customers. Suddenly, you remember something - www.learnalpha.com! There is an article written by Dr. Peter Wayne titled "Use XBASIC to restructure a Table". You dial in to your ISP, re-read the article, yes! You follow the directions exactly, cut & paste the Xbasic coding and have solved the problem of adding a field to an existing table in each of your Customers place of business.
Remember, this article may not be the ultimate answer to sending out Application Updates, your situation may be different. The important thing is, find a way that works best for you and then be consistent. An alternative may be requiring each Customer to have PCAnywhere. If you have one Customer per Application, thats fine, but if you have many Customers per Application, even PCAnywhere could become cumbersome and time consuming.
| Barry is an Alpha Developer living close to Newtown, PA. Home of James Michener & Pearl Buck who lived just up the road (though not together). Barry can be reached at brochford@enter.net |
11/17/99
Don't forget, we need your feedback to make this site better!