[fannatastic]

Originally Posted by Al Gebra

I'm afraid, no. I have all CC pics on my HD, btw. Some examples (from your original 'LL' list) - (my count):

.P, 1296f, LL, Forbidden Thrills, 28, , - .P, 1296f, LL, Forbidden Thrills, 26, LL34.?,
.P, 0197b, LL, Saucy Salon, 19, , - .P, 0197b, LL, Saucy Salon, 18, ,
.P, 0297f, LL, Rich & Kinky, 20, , - .P, 0297f, LL, Rich & Kinky, 20, LL34.?,
.P, 0397b, LL, Woman To Woman, 23, , - .P, 0397b, LL, Woman To Woman, 20, LL28.?,
.P, 0497b, LL, Hot Quartet, 20, , - .P, 0497b, LL, Hot Quartet, 20, LL33.?,
.P, 0597e, LL, Studio Game, 22, , - .P, 0597e, LL, Studio Game, 21, LL32.?,
...

Al, I'm not trying to take over your LL work. When I started on the missing lines, I thought "I don't want to do this anymore, there's a better solution" (see below). So I decided to complete the mag info for all the mmyy sets, which took less than a minute per set. Because I had promised to do some missing lines, I added this info by hand in a hurry, so as not to delay retro man. Sorry to everyone for the syntax errors.

I will not add any more missing .P lines myself. If the CC_CSVs contain up-to-date and accurate info, then data should be read from these CSV files instead. Why re-invent the wheel?

icu, could you please write a little program to extract the following data from the CC_CSVs files?

CC Set (from 4th field)
CC Category (from 4th field)
CC Story Title (from 5th or 4th field)
CC Pics# (from 1st field, largest number left of ".jpg")

These fields from the CC_CSVs files would overwrite the existing fields. This would solve the CC Pics# mismatches at the top of this message. Our existing Original Mag.Story# and Comments fields would be kept. The following fields should then be locked so that they cannot be changed by "user" updates:

.P
CC Set
CC Category if not blank
CC Story Title
CC Pics#
Original Mag sub-field if not blank (locked if mag specified already)
Story# sub-field if not .? (locked if story number specified already)

The updater program should prevent these locked fields from being overwritten. If new user data is not blank and is different to existing locked data, then the updater should generate a message showing original and proposed data. New data would be accepted and the change made manually (by icu) if we agree.

The Comments field is not locked. Any new comments to be added to end of existing Comments string.

Entire lines would not be locked while waiting for a particular person's data. Instead a "first come, first served" system could operate. Of course, we should try not to duplicate our work.

Is this a sensible scheme? We will need icu's programming skills once again. Also a few changes will be needed in the .P list beforehand.