Hi Jeff > 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.
Hmmm... Then there was an extraneous 1000 or something in your original post. You quoted PHOTOS as containing: [55 (C); 999 (B), 1000], which would result in three filenames, would it not? But never mind, that's beside the point now... > 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. Nope. You really should do this with a related table. But I won't get into structural questions here... > 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. No, just a related table... > 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-) Hmmm... Not really. But as I say database design is rather off the topic of this post. So are you able to pad out the appropriate parts of your photo name now? Steve
