Read Me

UploadService/README.txt

UploadService may be distributed under the license indicated at the source download site:
http://UploadService.sourceforge.net

UploadService loads binary images from a filesystem into a database.

The user must provide a stored procedure, or other data access tool, tailored 
to their site-specific database architecture (not provided here.)

CUploadFile and the (three) database accessors must be revised to match the data
access tool(s).

The images (binary data files) must be stored in subdirectories under a specified 
"root" data directory.
Each subdirectory must be labelled to uniquely identify a specific (case) accession
on the database.  (At our site, a stored procedure takes the subdirectory name and
attempts a unique match with a case accession.)

UploadService looks for a "marker file" [*.NLD] to indicate new "not-loaded" image.
The "NLD file" is deleted when the image (and thumbnail) are successfully uploaded
to the database.
The user application must create an NLD-suffix file with the same filename as any 
new image (not provided here, see http://specimenphoto.sourceforge.net).

UploadService is a ATL7 (Visual Studio) project for Windows2000/XP and higher machines.
It builds UploadService.exe which can register, unregister, install, debug, and run an
"NT-style" long-running service.

The UploadService cycles at a specified interval, generating a new CFileCollector object
which does all the work.  A database connection is established when UploadService starts.
The database initialization information is retained and reused with each new CFileCollector.
Each cycle begins with a new database connection.  This strategy assumes that new files are
infrequently generated and that UploadService can skip cycles if the database is not available.

CFileCollector holds two objects:

	CFindFilesToUpload recursively searchs for marker [NLD] files.
	
	CUploadFile finds the corresponding thumbnail and full-sized image files, extracts 
	metadata, and uploads these to the database.
	
CFileCollector and its progeny are destroyed at the end of each recursive search for
marker files.  A new CFileCollector is created with each cycle.