Create 12 different program shortcuts, one for each WWC session. And for each shortcut, you call a different config.fpw by setting Target to something like C:\wconnect\yourserver.exe -cc:\wwc\session1\config.fpw. In each of the 12 config.fpw files you have at least two lines:

ODOMETER          = 100
TMPFILES=c:\wwc\session1\temp

Make sure that you use different values for sessionX and ODOMETER (multiples of 100)

In order to be able to distinguish the different sessions in the taskmanager, you must add these lines to your main.prg

_vfp.caption='Session no ' + Transform(Set("Odometer")/100)
Set Odometer to 100 && Or whatever you prefer

Instead of using the odometer value to distinguish the different sessions, you can use sys(2023) to find the distinct name of the temp folder, and use that name to set the caption of the program.

>All,
>
>We have a customer with a quad-dual-core server with 12 WestWind COM instances serving about 200 hits/second.
>
>Every so often we're seeing errors like this:
>
>

LINE:1677 ERROR NO:1718 MESSAGE:File
>c:\docume~1\clinsu~1\locals~1\temp\0000duzd003g.tmp is read-only.

>
>Line 1677 is a SQL Select statement against an existing cursor into another cursor. We're assuming that 0000duz003g.tmp is the tmp filename allocated internally by VFP for the cursor result. Certainly it's not something we're creating ourselves.
>
>If this is correct, then we're expecting that every so often server instances are able to perform SQL Selects into cursors at precisely the same time, generating the same supposedly unique tmp filename with only one instance able to save its resultset into that file.
>
>The only way we can see to fix this is for each instance to use its own temp folder.
>
>We know that in VFP the tmpfiles location can be set in config.fpw, but changing that still leaves us with the same temp folder for all the server instances. We are told that you can also set TMPFILES if you add a "COMMAND = Do startup.prg" as the last line in your config.fpw and set TMPFILES in the prg. However, we have found that setting the value of TMPFILES in a startup.prg is ineffective.
>
>Hopefully somebody can tell us how to set tmpfiles uniquely for each instance or otherwise how to avoid this error which is catastrophic. FWIW we experimented with the code below which (despite having minimal trapping) certainly can create a unique folder for each instance but cannot assign it to TMPFILES.
>
>

*----startup.prg
>*----this prg creates a unique folder in the server's temp folder
>*----to avoid filename contentions in a multi-processor server running multiple instances.
>
>public pcUniqueTempPath
>local llNotDone
>llNotDone=.t.
>
>*---loop until unique folder created successfully...
>DO WHILE m.llNotDone
>   llnotdone=.f.
>   pcUniqueTempPath=ADDBS(GETENV("TEMP"))+SYS(2015)
>   *---using getenv() in case sys(2023) not yet available at this point...
>
>    TRY
>      md (m.pcUniqueTempPath) &&if we can create the folder it must be unique...
>    CATCH
>      llNotDone=.t. &&nope, somebody else got in first... so try again...
>    ENDTRY
>ENDDO
>
>*---Public variables are said to be naughty but in this case
>*---the application object does not yet exist so
>*---pcUniqueTempPath is public to allow cleanup before exit
>
>TMPFILES = (pcUniqueTempPath) *---is the above line wrong?