Is there any way to get an indexed symbolic field to update when the record is saved with an Rbasic "WRITE" command?

One of the few immutable wisdoms of AREV programming is

"Thou shalt not index symbolics"

An RBASIC write passes through the BFS (RTP57) the same way as any other write does (say from an editor F9 save or screen commit)

If the SI.MFS is detected on the file handle, an attempt is made to update the values of indexed non-symbolic fields with their new data values, and SI.MFS handles this.

If your index isn't updating now, there's little you can do to trigger the update, short of an index remove & rebuild.

You should consider whether the symbolic data can be somehow stored and then indexed automatically, or optionally, whether the source data from which the symbolic is composed can be somehow indexed instead.

If (for example) your symbolic was to perform

@RECORD=@ANS

every time it ran, then file writes would update field 107, and if field 107 were indexed, you could transfer the selections and btree.extracts on the file to field 107 and your issues may be (in part) solved. Depends on how you're using the index and how it's composed, and whether the symbolic field is fired off when you need, and comprehensively across the entire file.

Usually we would ask ourselves whether the data design is robust if the need arises for indexed symbolic fields. This approach is inherently problematic. If you must do it then see:-

http://www.sprezzatura.com/senl/volume2/v2i7.htm#_Toc458221440

The Sprezzatura Group

World Leaders in all things RevSoft

Actually, there are a number of circumstances in which the indexing of symbolics is a very desirable thing (e.g. to provide a single point of entry for a search which might look across a series of different notes fields, or to search for names which "sound" alike.) And why not check out Revmedia Volume 2, Issue 4 for a somewhat different philosophy on this technique (and no, it's NOT one of mine…! )

What's for sure is that you don't want to rely on indexing a symbolic which ultimately derives its data from a different table (and which is therefore not updated by the aforementioned RTP57/SI.MFS chain.)

FWIW,

Cameron

Whoops - hush our tongue… we missed the word external[/i] from our "immutable" rule. As you so rightly point out, indexed symbolics CAN be useful - in fact as every column in AREV/OI is a symbolic (albeit F types are of the form @Ans= @Record) it is impossible NOT to have symbolic indexes. Although naturally that launches another query as to whether the ! code uses calculate or but that's another matter. And as for searching FKBs - we've got online problems with our search indexes at the moment - hopefully they'll be fixed shortly. Toodles! The Sprezzatura Group World Leaders in all things RevSoft </QUOTE> View this thread on the forum...