hi steve, thanks.
In your case I'm not completely clear what data
is in Photos nor what the end result should be
(your calculation is given in some kind of
shorthand)... It looks like you want a
multi-line result.
actually it was the full calc, only the html was
shortened for reading. i should have mentioned
that "(B)" and "(C)" have to be stripped when
generating the web addresses. and, you are
correct: i need a multi-line result so that the
full web addresses can be listed in an email,
among other things. so, with "343 (B); 1527
(C)" as values in Photos field, the result of:
PHOTOS IN HTML is a calculation:
"http://address.com/DSC0" & Substitute ( Photos
; [ " " ; "" ] ; [";" ;
".jpg¶http://address.com/DSC0"] ; [ "(B)" ; ""
] ; [ "(C)" ; "" ] ) & ".jpg"
is (Photos in html field):
http://address.com/DSC0343.jpg
http://address.com/DSC01527.jpg
but i need a zero added before 343 in the 1st www.
You might, to preserve your sanity as you review
the calculations, create a separate calc field
for each part.... And it would be easier still
if you separated PHOTOS out into two fields, for
the number part and the letter suffix. You could
put them together in a calculation (for
searching), but you'd have a lot more
flexibility in putting together your html.
the Photos field contains photo documentation for
a media library collection (reels, DATs,
cassettes, etc.) and can have anywhere from 1 to
upwards of 20 values, each value being a separate
photo documenting a single media (we may have
several copies of a single work in various media
formats); this would require 20+ fields and seems
to be overkill to me.
the suffixes were easy enough to strip in any
case, and not all numbers are accompanied by
these suffixes (partly because the documentation
is actually incomplete). and then i would also
need upwards of 20 more fields for this secondary
information, giving: Photo1, Photo1_format,
Photo2, Photo2_format, etc.
I wonder really why you seem to have multiple
photo names stored in the one field. Likely this
would be much easier if your PHOTOS field
contained only one data point.
the database was created with each record
representing one work in the collection (as with
the media library). each media may have several
works on it. if each photo was a unique record,
i would still have this situation in reverse,
because somewhere i would have to indicate that
the individual photo refers to multiple works...
which might be entered in a field separated by ";
" or a return. 8-)
cheers,
jef