runtime application update

[Trixie dela Cena]

we have an a5v5 apps and wanted to upgrade other offices from a4 to a5v5. we are in the process of listing the things that would come up in the future if we make changes in the main dba and then have the other offices reflect the changes made. i have come up with the ff:

based on this msg board, the following files are needed for application updates for runtime users:
for form & reports layouts & properties - copy/paste ddd,ddm,ddx OR set,sem,sex files
table field(s) addition: i created a script for this

my questions:
how do you add/remove/update(rename,order,filter, etc) an index? how do you update(rename, change type/width/dec) the table fields?

thanks. trixie.

[Raymond Lyons]

RE: runtime application update

>> how do you add/remove/update(rename,order,filter, etc) an index? >how do you update(rename, change type/width/dec) the table fields?

[Trixie dela Cena]

RE: runtime application update

What I meant was in the runtime application updates. How could I be able to update the index and table once given to the offsite offices (they don't have the full version). If I make my changes on my main database and copy certain files, would that do the updates? or will there be another way to do it?

appreciate any input on this. trixie.

[Trixie dela Cena]

RE: runtime application update

if i make changes in my index, say rename or change the order expression, would the .cdx file be sufficient to give to the offsite offices?

[CALocklin]

RE: runtime application update

Yes, but...

Once they install the update, they would need to have a way (a button somewhere) to update the index so it is synched with their current data. Otherwise, the index taken from your table would keep finding the wrong records when used with their table.

FWIW: I prefer to have a script which completely rebuilds all indexes because I have had situations where customers have either lost or deleted required indexes. Now, they just push a Rebuild Indexes button on the maintenance menu to restore them all to the original state. It takes a bit more time to build the script but I find it worthwhile.

[Trixie dela Cena]

RE: runtime application update

i forgot about the Rebuilding the indices. does anybody know where i could find the sample script for Rebuilding index?

thanks. trixie.

[CALocklin]

RE: runtime application update

The easiest way to update the indexes when copying the cdx files would be with action scripting:

start a new action script, select "Add New Action", select "Database Utilities" / "Update Indexes"

The program will walk you through from there.

[DiFaz]

RE: runtime application update

Trixie,

If I understand your original question, you were asking about more than just updating indexes......

If you need to update the programming or formats of screens, reports, etc. you need to have at least one full version of Alpha on the network. you can then do your changes in the full version and notify the other users that they need to "refresh shadow" Like indexing, you can automate refresh shadow for the users with action scripting.

Hope this helps,
Ray DiFazio

[Trixie dela Cena]

RE: runtime application update

thank you for all your help.

Cal, I ran the Action Script you said and it is working great. That would take care of my cdx updates. thanks.

Ray, I have both the Runtime & the Full version. I don't have problem with the onsite updates (so far) but more concern with the offsite updates. We would like to find an easier way to update them like the table, index, forms & etc.

i guess as far as table properties/structure is concern, we need to either manually go behind the scene and modify it or create a script for it. does anybody have more ideas on this?

thanks. Trixie.

[Tim Stephens]

RE: runtime application update

Here is my method for updating offsite databases in alpha 5.

The following method assumes that the production database (clients db full of data) is on a server and workstations access it through a shadow database.

1) I run a batch file on my machine similar to the following: (the batch file is executed in the folder containing the latest version of the program. (The version I want to distribute)
md build
copy *.dd* build
copy *.fpt build
copy *.se* build

copy *.adb build
copy *.al* build

rem the rest are application specific
copy *.xls build
copy *.exe build
copy *.bmp build

2) Copy the "build" folder to the clients production database, overwriting all the current files. (note: the dbf and cdx files containing the data and indexes are not overwritten)

3) The client then opens the database (not a shadow!) from one of their workstations (using the a5 runtime). They goto a form which has a button to "update" the program, this just executes a script that does any table (.dbf) changes if necessary. ie) if adding a field to a table, this would be added here.

4) The client then starts up their application normally (from the shadow) and it will ask to update each workstation. And we are finished updating.

Index's don't need to be rebuilt unless step 3 makes modifications that would corrupt the index.

In step 3 it is important to open the production database file (not a shadow) as this makes sure that the table references are not corrupted. (otherwise data would "appear" to be missing).

I hope this is helpful, it isn't the only way to do it and I'm sure it is not the easiest way either.