Item Note as attribute type "Data"
 

Kinook, I notice that the Item Notes attribute is declared as type Data rather than type String.
What is the benefit of Item Notes being declared as type Data?
Are there ways that users can exploit this?

Because Item Notes is not just a string -- it holds formatted rich text data (and is stored compressed in the database).

Item Text appears to be declared as type String and it holds formatted rich text.

I take it then that there is nothing extra special that we can do with Item Notes compared with Item Text?
Unless perhaps Item Text is NOT compressed? Then, to minimize database size we might tend to put things like pictures in notes rather than text?

Item Text is a bit different than Item Notes.

Items Notes is always edited and stored as compressed RTF. It is accessible in various ways (edit in Notes pane, print, export as RTF, search on keywords or text, show text in column of Related Items pane, etc.).

Item Text is the string text associated with the details of an item. It's source can be RTF (for Text items), HTML (web pages), PDF files, etc. Regardless, the underlying data is stored compressed in the database. Item Text, the attribute, is the string text for the item's details. It is also available in various ways in UR (displayed in the detail pane according to its document type, edited externally as a document, search on keywords or text, show in Related Items, export as raw text, document, RTF, etc.).

Excellent - thanks heaps for your prompt response.

You commented "...Item Notes being accessible in various ways...show text in column of Related Items pane... Sure, Item Text & Notes can be selected as columns however (the first line of) their contents doesn't seem to show. This is not a big deal, I hadn't even considered showing those attributes in a grid until testing it a moment ago. I wouldn't change the program - just be careful not to boast that you can show Item Text & Notes as columns.

Another side effect of disabling keywording for .rtf, which will be fixed in the next release. Be aware that non-keyworded searches will get progressively slower as the database grows, while keyworded searches will remain very fast.

Cheers.

I'm keen to observe UR performance without item text & notes being keyworded. Personally, when I "quick" search, I only want items returned that match the "other" attributes. When I can't find something or want to do some more advanced cross-referencing, I'm prepared to wait for a "deep" search to execute.

Hopefully at some stage I'll figure out a way to take a representative real life database and generate the keywords for item text & notes. Then I'll try to give Kinook an example as to how much of a performance difference there is. Armed with that feedback some users might prefer to sacrifice item text & note keywording to improve overall performance.