Agreed. However I'd divide the list of files to be processed into 4 or 5 or whatever separate tables so there's no messing around with row locking/contention or any possibility of skipped files.

>Harsh, the way I would do it (assuming I understand the project):
>
>First, create a table of file names to convert - see ADIR() function.
>
>Now make a conversion program that accesses this file and does this:
>
>1) search for the first unlocked record,
>2) attempt to lock the record - if failure then try another record (attempt once only, don't bother with retries)
>3) convert the file as stored in the record,
>4) delete the record,
>5) repeat at step 1
>
>The program runs in a loop and the user can exit it in some way e.g. pressing Esc.
>
>Now I can simply load as many copies of this program as I like and the computer CPU itself will decide what core to run it in. In this way my program is simpler to manage, the computer takes care of multi-processing issues, and I can fire up as many copies of the program as I think appropriate by observing the CPU and disk usage performance.
>
>
>
>
>
>>In that case you mean to say That of I have 20000 Records in a Table say A. I shall divide it in A1,A2,A3,A4,A5 Each with 4000 Records first.
>>And than I should process Each table in a separate CPU. Is it what is suggested.
>>
>>If yes, than kindly tell me how will I bind my A1 table and related records to CPU1 and A2 to CPU 2 ?
>>
>>Harsh
>>
>>
>>>Harsh, make sure you read Al's post regarding not using Parallel Fox and instead modifying your application to accept a parameter to process a section or group of files. And then you load several copies of your main application, each processing a different group of files. The advantage of this are:
>>>
>>>1) Far simpler model - no need to mess around with Parallel Fox, threads, etc. Your app is a simple file conversion app (but needs to take a parameter to determine files to process, or it must ask the user for which files to process, or you can create a database of file names and lock the record you are processing and each copy of your app just looks for the next not-locked record. There are various options.
>>>
>>>2) By running multiple copies of your app it allows the processor to decide which CPU core or thread to run each copy on. More efficient.
>>>
>>>3) You can load as many copies of your app as you like - watching CPU and disk usage to judge performance - stopping copies and loading additional copies without code changes.
>>>
>>>
>>>