Quick way to add table field to master copy of a shadowed database

[brett s]

Is there a shadow database expert who can answer this question for me.

If I add a new field to a table in my A5 master database (which runs on a server) will the shadowed copies of this table on users' networked PCs see the new field automatically, or must I refresh the shadows on each user's PC separately?

Thanks.

[csda1]

Re: Quick way to add table field to master copy of a shadowed database

Brett,

The shadow only uses pointers to the master table, index and memo files (DBF, CDX, FPT), so, yes, it immediately will access those tables. However, those fields won't appear on any layouts (unless dynamically created by code, e.g. default form/browse), and any references to indexes by name will use the new expression on the master for the computation. LQO happens dynamically, so they will use the appropriate index as it currently exists.

I use a variety of my own support functions that are tolerant of changed fields and just ignore them or do something reasonable with them, but that's not in most A5 functions.

[brett s]

Re: Quick way to add table field to master copy of a shadowed database

Thanks, Ira. I think my master and shadowed databases will be OK then. Yes?

My customer is 500 miles away so when things go wrong it can be difficult to sort them out. I previously sent him a new version of this A5 application, one of the changes included adding a new field to a table. This was done via the 'a5_add_fields_to_table()' command which tested out OK (definitely no bugs) but for some obscure reason failed when run via Runtime on his Windows 2003 SBS - an error message advising "Corrupt area".

Every thing in the master database has updated OK (put there by update installer), it's just the new field that has not been added to the table.

So it sounds as if all I now need to do to get things up and running again is just manually add the new field to the table. Thereafter the shadow databaser's on each user's PC (which have already been refreshed) should pick up automatically the new field in this table. I certainly hope so.

[csda1]

Re: Quick way to add table field to master copy of a shadowed database

Thanks, Ira. I think my master and shadowed databases will be OK then. Yes?

Seems like it would based on how you described it.

[Garry Flanigan]

Re: Quick way to add table field to master copy of a shadowed database

Brett,
My memory is that you will have problems if the field is added anywhere other than at the bottom of the field list.
Even changing the order of fields without refreshing a shadow will cause problems.
Why don't you have the application automatically refresh shadows when the version number changes?

[csda1]

Re: Quick way to add table field to master copy of a shadowed database

Garry,

While that was true for a few places in Alpha 4 and maybe some early versions of A5, I don't believe there is any place other than a restructure of a table where you are moving fields around and changing them (and even there only in very specific obtuse ways) is the fieldname position important.

So I'm saying you can add fields to your hearts content anywhere in the structure, or move the fields around. However, renaming them or changing types and sizes affects fieldrules, tables, expressions etc everywhere, so that is important. In most cases changing field size does not matter, but only if you have no field length specific code.

If anyone has any recent proof to the contrary, I'd be interested in hearing about it.

[brett s]

Re: Quick way to add table field to master copy of a shadowed database

Brett,
Why don't you have the application automatically refresh shadows when the version number changes?

Garry, this is indeed what I always do when I produce a new version of this application. This latest version included many changes, including a new field added to an existing table.

The application update installer first gets installed on the server. It includes updates for everything except tables (including their indexes and fpt memo files). In this case I got them to next run the application on the server so that the new field would add to the table (via my autoexec script). Then the networked PC shadow databases were run and the applications there automatically updated because I have told A5 to do this when the application version number changes.

The problem occurred when we got an error when the application was run on the server "Corrupt arena", (not "area" as I previously stated). If that message is supposed to mean something to anyone, well ...

I eventually discovered that the table I was adding the new field to had corrupt linkages for the memo information and this caused a whole lot of downstream errors and problems which were starting to grow to Everest proportions.

The best and quickest solution for me in these circumstances was to get a copy of the errant table sent to me, fix it up, send it back and have it installed on the server. As long as the shadow database copies on the networked PC don't object then this solution should work. And this is the reason for the original question in this post.

Another option for me if this solution does not work is to do a shadow refresh. But for reasons I do not understand this has never worked reliably for me as I get only partial updating take place and parts of the refreshed shadowed application that incorporate the latest changes do not work. A full shadow rebuild with a new application version number is the only thing that I have found works reliably. In these circumstances doing a rebuild with a new version number means a lot of extra time. A new version requires a lot more QA before shipping than the table fix which does not.