We help IT Professionals succeed at work.

MFC creating temporary files as a program runs?

markley
markley asked
on
436 Views
Last Modified: 2013-11-20
I've developed a program using VC++ 4.2 and MFC.  
Comment
Watch Question

Are you using temporary files in your application? Do you get them via the GetTempFileName?

Author

Commented:
I'm *not* using temporary files in my application.   These files are *not* being created by my program.  

I figured it had something to do with debugging information.   However, I've compiled and run in release mode but the temporaries were still generated  :(  I've also disabled "just-in-time debugging", but that didn't help either.  I didn't see any other relevant switches/settings to play with

Author

Commented:
I'm *not* using temporary files in my application.   These files are *not* being created by my program.  

I figured it had something to do with debugging information.   However, I've compiled and run in release mode but the temporaries were still generated  :(  I've also disabled "just-in-time debugging", but that didn't help either.  I didn't see any other relevant switches/settings to play with

Commented:
You shouldn't be using oFstream, this stream stores an object of class basic_filebuf wich means that eash time you create a stream, you create a temporary file!
Use an ostream instead.

Author

Commented:
I'm not totally sure if I agree with this for a couple of reasons.  First, I use ofstream for *all* of my file I/O.  As the program runs it will wirte, on average, about 40 different files to a given directory.  However, only *ONE* temporary file is present within that directory.  If a temporary is created each time I create the stream, why wouldn only one temporary be present in each target directory?   Secondly, the information contained in these temporaries has absolutely nothing to do with the information I'm writing to the file.  

I've taken a closer look at one of the created temporaries.  Again, they are binary files.  The contents of the file looks as if it's the information I've read from a table in our database.  I'm using a Recordset to grab a number of records from a table.   The contents of the binary file appears to be a record from the Recordset, a series of bytes with the value of x00, another record, a series of bytes with the value of x00, another record, etc......  There is *one* of these files in each directory I perform file I/O.   I'm opening the Recordset as a snapshot.

I do, however, use Recordsets elsewhere in the program, and access completely different data.  It seems odd that the contents of all these temporary files contain only records found in *one* of the Recordsets I use.  Well, there's some more food for thought.......  :D  


Author

Commented:
OK.  *I* solved the problem as to why temporaries were being created everywhere.  Within the program, the current working directory was being changed.   The code was changed so that the current working directory remains consistent throughout the execution of the entire program.  After the change was made, I watched the contents of the working directory as the program ran.  The temporaries were created once again.  The number and size of these files fluctuated as the program ran.  Upon termination of the program, the temporaries disappeared entirely. Obviously, this is the desired outcome :D

It's obvious the temp files are being created by some MFC code. Are they created for debugging purposes?  Is there a setting I can use to prevent the creation of them?  Or are these files simply the result of an implementation detail of MFC which I have no control over?
I has an experience that temporary files are generatied while using ODBC with MFC. It was in Windows 3.1, we used CRecordSet to access Access database. Few temporary files were generated, they are deleted if the programs doesn't crash.
Those files are generated not by MFC, but by ODBC drivers ( we used Microsoft Access 2.0 driver). The Cursor Library ( part of ODBC ) creates a "snapshort" of returieved records and the scrolling is done over this snapshort. THis allows scrooling over records, even if the dricer of database doesn't support scrolling.
Until you call the "Requery" function of record set this "snapshot" is not updated, you cannot see the changes made by other users.
The Cursor Library created temporary file for the snapshort. Probably this will not happen if you use dynaset or use DAO ( if you can with your database). For Microsoft Access datavase it is better to use DAO, the class CDAORecordSet is similar to CRecordSet and works faster.
Yours, Igor
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.