Bob,
I don’t think corruption is the issue. When you have a note field on a row with other data, a certain amount of space is allocated to a null NOTE. Adding data or expanding an existing NOTE may cause the row to relocate. That just takes a little time, probably negligible today, and a little more space. By using the second table, you avoid that issue in your main table. As Mike has noted, you can use a generic table for all NOTEs and restrict the above issues to that one table. This is to my way of thinking superior to setting aside a TEXT 300 for instance, where space will be consumed for every row whether you have data or not. You can also use a varchar datatype and store your “notes” in file 4. Emmitt Dove Manager, Converting Applications Development Evergreen Packaging, Inc. [email protected] (203) 214-5683 m (203) 643-8022 o (203) 643-8086 f [email protected] From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, December 17, 2009 2:43 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Note Data type question Thanks all and I appreciate the input. To recap, I know of and have implemented a few ways to handle notes in a separate table. Some similar to what has been listed and I do not have any trouble doing that. But that was not my question. Alastair, Emmitt and Karen came closest to what I was inquiring..... The only reason I would use (not how to use) two tables in this case is that there (might?) be a higher risk of losing data using a NOTE data type in the main record, or that editing a Note data type might cause the entire record to be written to a different physical spot on the disk. (Thus eating up space over time) However editing the Note data type in the second table would do the same thing, so this might be a moot point. That leaves the higher risk of having a problem when retrieving a corrupt record as being the main consideration. I.E. it is better to lose just the note than the whole record. I will make my decision based upon that. Thanks again. -Bob
