One disadvantage of using a VARCHAR over a note, though. One client of mine uses the table browser alot and then exports to Excel from there. Note fields come over, but varchar fields obviously do not. For this reason we changed some fields back to NOTE.
Karen > Tom – > > > > It’s really your call – here are some points to think about: > > > > 1. When you have a table with a NOTE field, then the width of the > record is variable. In the rare event that you have corruption in this > table, > you cannot use the automatic fix option in R:Scope – you’ll have to fix the > records manually. > > 2. When a note field is edited, if additional characters are added to > the field, depending on the NOTE_PAD setting, it may require that, > internally, R:BASE will delete the current record and copy it to the bottom > of the > data file since all the new characters won’t fit into the original space. You > can control this somewhat by increasing the NOTE_PAD value, but then you may > be > storing lots of blank space. In addition, you may wish to RELOAD the > database more often to remove the blank space that accumulates when a record > has > been deleted and moved to the bottom of the file. > > 3. In older versions of R:BASE there were limitations as to the > flexibility of the VARCHAR data types – but now they are pretty flexible and > can > be managed in pretty much the same way as a NOTE field. > > 4. Whereas there is a size limit (mentioned below) to a row using a > NOTE field, the size of a VARCHAR field is 256MB. So if your users will be > entering lots of text, the VARCHAR field may be the way to go. > > 5. VARCHAR fields also allow font and formatting settings to be saved > as part of the data itself – so if your users need that flexibility, then > use a VARCHAR. > > There probably are more differences – perhaps others would chime in with > their thoughts. > > > > For myself, in the last few years, I have tended to use more VARCHAR fields > than NOTE fields. > > > > JMHO! > > Sami > > >
