There's one thing I never had any use for until now, and that's sub-values in table data. With sub-values I mean multivalued fields where each value again may have several (sub-)values. I thought the natural thing for sub-values was to use @SVMs between them. But (surprise, surprise!) edit tables don't handle data with @SVMs well. When data are read into an edit table each cell value seems to be stripped down to its first sub-value. Of course in an edit control @SVMs show as the character, and that's not user friendly either. But in my case the edit table is hidden, so the 's are no problem. The data is shown and manipulated in a more user-friendly way in a different control.

I assume the obvious solution is to use a different character as a sub-value delimiter, but if there's an alternative that can save me from changing all my current programming I'd like to know.

TIA,

- Oystein -

Oy ..

You are correct that @SVM's don't work well in DB_TABLES (but they may need to be there anyway due to form-bound I/O). As you point-out, you can hide the control and deal with the @SVM data in other more convenient ways. We tend to use Dialog Boxes for this. You can use @SVM data in symbolics by deliting them with something more readable: SWAP @SVM with "," in @ANS where @ANS is an MV / SVM delimited array.

@SVM delimited data does work well in control structures where @VM's can be parsed easily and extracted. Then the @SVM data can be parsed as well.

Don Miller

Don,

Thanks.

I can (1) either keep @SVMs in my data tables and hack something with the edit table, or I can (2) use a different delimiter character everywhere.

But what about indexing? I may need indexes on fields with sub-values. Does that work OK with @SVMs? I mean will each and every sub-value be indexed? I would assume so.

If indexing works with @SVM that is an argument in favour of (1). With (2) I would need to use symbolics (with the delimiters converted to @SVMs) and index them instead.

- Oystein -

Oystein ..

In AREV, @SVM's are properly indexed in B-Trees. I would assume that OI would be no different. I have used @TM's even and have had indexes come out correctly..but your phrase "each and every" makes my blood run cold (as do a lot of other things these days) , but what the heck…

Don M.

Oystein,

First, we have seen no problems with @SVM, @TM, or @STM with regards to indexing.

Second, we have used the approach that Don suggested to display fields with low level delimiters within an edittable. For instance:

Create a symbolic that only displays the first "line" of information of a delimited multi-valued field. Use this to display the information in the edittable. That way the end users won't see the funny characters being used as delimiters. The end users would have to double-click (or press a hot key) to open a dialog box to edit the actual data. The true data would then be in a hidden control on the form. This approach is similar to Cameron's article on binding large data fields to the edittable. An additional feature would be to leave the column unprotected so the end user can type in the cell. Naturally this won't have any true impact on the data, however, you can trap this entry and then auto-update your true data. We prefer this approach because it best simulates how the AMV text fields worked in AREV.

[email protected]

SRP Computer Solutions

View this thread on the forum...