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

Reply via email to