Modifying applications once they are done.

[Wags]

Hi,
I'm very new at this so please be patient. I've created a small application using the runtime and Alpha 5 Ver. 7 and have distributed it. Everything works great but I have a question on the procedure of how you make changes to the program over time (new reports, new forms etc...) to the orginial code without losing or changing the existing data.

I can't seem to find an answer but suspect that I'll have to write some code. Is there anyone who may be able to past on some helpful advise.

Thanks

[trackmanpete]

Re: Modifying applications once they are done.

I am not sure but perhaps this link will start you in the right direction.
http://msgboard.alphasoftware.com/al...updating+files

[Wags]

Re: Modifying applications once they are done.

Thanks very much. I saw some good ideas. I think I'll try a few experiments here before I even attempt it at the clients.

Thanks again for all your help.

Mark

[Bob Houle]

Re: Modifying applications once they are done.

Here's a small program that I use to update my clients.

Note: If you change any table "structure", this program will not work. See the notice in the program.

I've used it successfully with some large programs, it makes changes a breeze.

--Bob

[Mike Wilson]

Re: Modifying applications once they are done.

Bob,
Sweet! Thank you.

[Wags]

Re: Modifying applications once they are done.

Here's a small program that I use to update my clients.

Note: If you change any table "structure", this program will not work. See the notice in the program.

I've used it successfully with some large programs, it makes changes a breeze.

--Bob

[Wags]

Re: Modifying applications once they are done.

Thanks a lot Bob. I'll take a look at it later tonight. I'm probably going to have to use it as of tomorrow.

Thanks for all your help!

Mark

[CALocklin]

Re: Modifying applications once they are done.

FWIW, here's my process for installing an UPDATE and the reasoning behind it: (The FULL install includes additional files.)

- I use a full-blown, 3rd party installer. (Astrum in my case.) The reasons for this will become clear below.
- The update installer always installs ALL application files. I used to install only the ones that had been changed but (a) that took a lot of extra time for me in order to save a few seconds of download time for the user and (b) far more important - too often this meant that I forgot about something and then the update didn't work.
- Only the application files (a.k.a. data dictionaries - *.al*, *.dd*, *.se*, and usually the .adb) are stored in the install file. The good thing about the installer, compared to a zip file, is that the file list is stored and they are automatically retrieved each time the installer is used to create a new update - no need to redefine the list means less chance of missing something or adding something that isn't needed. (Sometimes there are extra tables or sets that were used during development but aren't needed for the application. I'd rather only select/deselect them once.) It also means less time required to build the next update routine - just open the install builder program and click the "Create Installation" button. That's it - period.
- The installer is set up to install the udpate files to wherever the main data is stored. (see the next item)
- In the autoexec script there is a short xbasic routine that sets a registry value that stores the path from the local computer to the main data. I put the registry value under HKCU/Software/<MyCompanyName>/<TheAdbName>/DataPath. This is stored every time the application starts because (a) it happens very quickly and (b) if the application gets moved for any reason, the value needs to be reset. The install routine is able to read this registry value and use it as the install path - this means the update can be installed from any workstation by virtually any user regardless of their computer expertise (or lack thereof!)
- The installer allows me to create a ReadMe file that is automatically displayed. I almost always list the updates here along with the date and version number. This means the user can read about the updates and, even more important to me, it also serves as a record/reminder as to what was updated and when it was updated. (OK, I sorta lied above. Creating the update as I do, it requires more than clicking the button - I also change the version number and update the readme. However, the point is that I don't have to.)

Although this is not required for the Update, the full install also builds the startup icon(s) on the Desktop and/or Programs list. And, it can use variables to do it which means that the user is free to install the program in any folder they choose. In one or two cases I even set up the Update routine to prompt the user to re-install the icons just in case they had been deleted - try that with a zip file!

The Astrum installer is even powerful enough to set variable values based on what is installed on the computer and use these to determine what to install. For my addin routines, the installer is set up to create variables for the A5v5ExeLocation, A5v6ExeLocation, A5v7ExeLocation, A5v8ExeLocation, and even the A5v9ExeLocation in some cases (just planning for the future) based on the registry entries (or lack thereof) then installs the appropriate files to the any location that is not "None". I use this feature most for my addin routines but have also used it in a few other special situations. (Don't recall now what those situations were but I do remember doing it.)

Another reason for using the installer for update routines is that it can be set up to NOT run the update if someone does not have certain files already installed. In other words, it can check for the existance of a file. It can check multiple drives for the file and is actually pretty fast at it but, since the install path is read dynamically from the registry, it is easy and real fast to check the install path for a specific file and not allow them to install an update if that file doesn't exist. There are also built-in variables for common folders such as the SystemDir, WindowsDir, SystemDrive, ProgramFiles, etc. so you could easily look in those folders and their subfolders also. Similarly, it could be used to check the registry for a registration number or other value.

Combine the above with the fact that the FULL install can be set up to require a serial number in order to run the installation and you have a user friendly but secure application installer.

Full blown installers like Astrum aren't for everyone but for anyone who expects to build multiple installation files or update files, they can make life easier for you and your customers. Most people may not expect to distribute multiple updates but if you are distributing a generic application I can almost guarantee that you will be building more updates than you expected. (Of course, my updates are only needed to add new features; it's never because of programming errors.)

[brett s]

Re: Modifying applications once they are done.

Cal, this is really good! Thanks for taking the time to explain it. A couple of questions:

Q1: Do you have further information available on how I would go about setting up this capability, e.g. the code in the autoexec script, example content for the the Astrum created installer, etc.

Q2: How do you handle changes to table structure. In this case I would want the Astrum-created installer to run an Xbasic process just once to modify the table structure (new fields etc.) and then copy the user's data from the old to the new table.

[CALocklin]

Re: Modifying applications once they are done.

Q1: Do you have further information available on how I would go about setting up this capability, e.g. the code in the autoexec script, example content for the the Astrum created installer, etc.

Actually, I have a standard function (stored in my code library) that I call from the autoexec. Here's a simplified version. Just create the function and call it from your autoexec. Of course, you will probably want to change the company name but you can either do that in the function or in the call to the function. I made it an argument so it could be used by other companies without modifying my proprietary function.

'Date Created: 21-Dec-2002 10:28:37 PM
'Last Updated: 30-Jan-2007 07:30:36 PM
'Created By  : Cal
'Updated By  : Cal
FUNCTION Aims_reg as C ( Company_name="AIMS DataCom" as C )
   'Description:Proprietary - creates registry entries for AIMS DataCom applications to assist in updates and troubleshooting. Can be deleted without any affect on program. Main data is in "datapath".
   'ALL THESE FEATURES ARE IN MY PROPRIETARY VERSION BUT NOT IN THIS VERSION POSTED ON THE MESSAGE BOARD:
   'IF running shadowed, create:
   '    ShadowPath, DataPath, LocalVersion, MasterVersion, and ShadowDate.
   'IF not shadowed, create:
   '    Data_Path, MasterVersion, and DirectDate.
   'For both types, show the last date used for the Runtime or Full version:
   '    RDate if using runtime or FDate if using full version.
   '******* NOTE: This seems to run as though set to OPTION STRICT when running shadowed.
   DIM appname as C
 
   DIM datapath as C
   IF a5.Get_Master_Path() = ""
      datapath = a5.Get_Path()
   ELSE
      datapath = a5.Get_Master_Path()
   END IF
 
   'Determine current app name.
   appname = file.filename_parse(a5.Get_Name(),"N")
 
   'Registry.sys_set() can't be used here because it only resets EXISTING values.
   'Write it to the registry.
   Registry.sys_create("HKEY_CURRENT_USER\Software" + chr(92) + Company_name + chr(92) + appname + "\DataPath", datapath )
 
END FUNCTION

As far as an Astrum sample goes, there's really no way to show the content on this message board. If you have a copy of Astrum and want to see an example, e-mail me and I will send you one of my .ai2 files so you can open it with your copy of Astrum. Of course, it won't work on your system because you won't have my paths and files but at least you can see how it was done.

Q2: How do you handle changes to table structure. In this case I would want the Astrum-created installer to run an Xbasic process just once to modify the table structure (new fields etc.) and then copy the user's data from the old to the new table.

Only Alpha Five can run xbasic so don't expect any installer to do it. However, it's not difficult to do it in the autoexec - but there are many variations. A simple IF statement can be used so it will only be done once. I'll show a couple basic methods to get you started.
NOTE: See the above script to find out how "datapath" is set. This is used to be absolutely sure that the main data table is updated and not the shadowed table. I don't know how it works today but I'd have to guess that at some time in the past it tried to modify the shadow table if you didn't specify the main table.

Here's how to simply add a new field:

'Add field "Patnt_nof" to the Inv_Items table if necessary.
fld_list = a5_get_fieldnames( "inv_items.dbf" )
IF .not. ( "Patnt_nof"$fld_list )
   new_list = <<%list%
Patnt_nof,C,6
%list%
   a5_add_fields_to_table( datapath + "\inv_items.dbf", new_list )
END IF

And here's how to change a field size:

'---------------- Change size of Def_agnt field in Clients table if necessary. 2006-04-05
tpc = table.open( datapath + "\Clients.dbf" )
fld = tpc.field_get( "Def_agentf" )
fwid = fld1.width_get()
tpc.close()
IF fwid = 20
   Old_list = <<%list%
Def_agentf,C,20,0
%list%
   New_list = <<%list%
Def_agentf,C,30,0
%list%
   a5_changefieldsize( datapath + "\Clients.dbf", old_list, new_list )
END IF

Notes:
- Both restructuring functions can take multiple field definitions. Only one is shown in these examples.
- The updates should be dated because they must be kept in the proper sequence.
- These scripts were created with basic v5 functions. There are other v5 functions and newer functions available in v6 and later such as table_restructure() and A5_field_info() that could also be used. See the Help file under "Field Functions and Methods" and "Table Functions and Methods". Remember that some of the new or more inclusive functions may be a bit slower because they are simply "wrappers" for these basic functions to make them easier to use. In most cases the extra time will be unnoticeable. However, one of my apps has so many updates now that it takes about 1.5 seconds just to check for all of them even if they've already been updated. Once I get all my users up to the latest version I will be able to get rid of most of them - but until then users will have to wait the additional 1.5 seconds for the app to load.

Hmmm, I don't think that "datapath" is needed in:
tpc = table.open( datapath + "\Clients.dbf" )

[brett s]

Re: Modifying applications once they are done.

Many thanks, Cal. This is really good.

[jkletrovets]

Re: Modifying applications once they are done.

Agreed! Thanks Cal!!!

[oldtony]

Re: Modifying applications once they are done.

Here's a small program that I use to update my clients.

Note: If you change any table "structure", this program will not work. See the notice in the program.

I've used it successfully with some large programs, it makes changes a breeze.

--Bob

Is there any way to run this neat program & not have the customer use a CD. I want to send the update folder over the internet & copy to a folder?
thanks
old tony

[enstorms]

Re: Modifying applications once they are done.

Cal,
I've got this posted in the v9 forum, but as yet, no takers. I cannot get this code to add fields to a table. Keep getting the error that "field - expression types must match..." Here's my code.

dim datapath as c
if a5.Get_Master_Path() = "" then      'if not a shadowed database
    datapath = a5.Get_Path()
else
    datapath = a5.Get_Master_Path()    
end if
'debug(1)
'add a field "Total_Charges" to the Reservations table in the database
fld_list = a5_get_fieldnames("reservations")   'get ctl-lf list of fields in table
if .NOT. ("Total_Charges"$fld_list) then       'if "total_charges" is not in list then add it
    fields = <<%str%
Total_Charges,N,10,2
Pctdep_Req,N,3,0
Dep_Req,N,10,2
%str%
    table.Add_Fields(datapath+"\reservations.dbf",fields)
end if
'debug(0)

I've taken this version of the code right out of the help files. (table.add_fields()) Can you see from this what is causing the error, or is more information needed?
Thanks.
Ernie

[CALocklin]

Re: Modifying applications once they are done.

I don't see anything obviously wrong. Is it possible that one of those other fields, Pctdep_Req or Dep_Req, already exists?