One item that has not been mentioned so far:
There are some compilers (REX is one of them) that open the database and make
the database items program variables, allowing you to reference specific items
with the name specified in the schema.  In such cases the source MUST be
re-compiled when performing any changes to the database.

Regards
Paul H. Christidis

____________________Reply Separator____________________
Subject:    Re: Settle an image dispute.
Author: [log in to unmask]
Date:       11/17/99 1:03 PM

Gavin and Denys have already discussed about everything I can think of specific
   to Image and how data could be corrupted or uninitialized or mismatched in
   the buffer. I'll give the 'generic' view.

If your change to the dataset (or formfile or flatfile or ksamfile or ...)
   causes more data to be returned to the receiving buffer in the program, it
   had better be large enough to handle it or the FREAD call (DBGET = FREADDIR)
   will happily overwrite whatever lives past your buffer on the stack. Little
   things like other variables or
bigger things like stack markers. This is a MAJOR source of DMPT (data memory
   protection trap) and other various traps depending on what got corrupted.
   When I worked in the RC, the DMPT call (several a month) would go something
   like this:

Cust: I got a DMPT and I didn't change my code.
Me  : Does this program use Image or Vplus and did you change the dset or form?
Cust: Yes
Me  : Make sure buffer is big enough.

Just make sure that the receiving buffer matches what the 'read' is asking for
   (or has extra room in it).

Like Deny's said 'It depends'.

Timothy Hoefner wrote:

> I recall hearing that it is not necessary to recompile a program just because
   a new item has been added to a dataset.  That is of course that the program
   declares each item being accessed and that "all-list" is not used on the
   affected set.   The dispute is that you must recompile regardless of how the
   list is defined in the program.
>
> Can anyone steer me toward a document that would contain this kind of
   information.
>
> Thanks a lot in advance and I hope I made sense!
> Tim
> [log in to unmask]