>Carl,
>
>Sorry if I gave that impression. That was not my intention.
>Maybe I just need a little educating.
>
>I am always interested in different ways of doing things.
>I have always done my temp files on the local hard disk, as the applications I have in place deal with large files and, in my experience, on already tasked lans, I have had to be very careful about not eating up too much bandwidth.
>
>It just seems wasteful to get your data-chunk from the lan, convert it to a file (locally), then put it back to the lan, use it for reporting, and then remove the file? This seems like more load on a server than needs be.
>
>I am really curious as to what the benefits of doing this are. I
>I fully respect your opinion, and have learned much from other developers, as there are often many different approaches that are overlooked.

OK, that's cool. My last contract using FPW2.6a turned up some interesting
things. It was running on a Novell network, I do not remember what version.
The PC's in use by multiple users were VERY VARIED! That is what precipitated
my delving into why some machines ran faster using the network drive for
temp files and some worked better with local drives. Many things came into
play and it was NOT fun (although it was interesting) to get everyone's PC
to perform quickly. Some people had very new machines with VERY FAST local
hard drives while other people had older machines with limited disk space
locally and the local drives were actually slower than using the network
drive for certain tasks (memory was important also). My final analysis was that I had to allow the user the ability (not just by using config.fpw but by a special config.dbf where I stored the path and drive assignments for an individual user) to dynamically point where he/she wanted to do temp drive and sort type activities. Each user had the ability to change the configuration for his/her signon - now that was not great when they moved to another machine but most of the people stayed at the same station. Anyhow, I discovered that a) You have to test each inidividual setup for speed, b) The user must be able to change the work files without modifying config.fpw, c) User's love it when they can change their environment without relying on a programmer to make the change.
I guess I have just learned that flexibility "without getting the programmer
involved" makes users very happy.
Thanks for your input. Just when I think I have it all figured out something
else pops up. I guess that is why George Goley said in an article in FPA last
year that "there are no experts". The releases change so fast, the machines
change so fast, you have to evaluate things individually. I read an interesting
article in, I believe FPA, about using the deleted() tag in indexes on a network. With large files it can be bad because the entire index (*.cdx) has to
be transimitted. Dropping the tag from the index makes a huge difference in
response time "FOR SOME SETUPS and application designs". I experienced that on
that same contract I mentioned earlier, small files were fast, as they grew, the
delete() tag slowed things down. I had to make changes for that but I never
understood why it worked - Mr Goley (maybe it was someone else???) explained
that in the article.
Man, this business keeps us jumping, reading, and learning!
Carl