Solved

MFC creating temporary files as a program runs?

Posted on 1997-11-18
8
335 Views
Last Modified: 2013-11-20
I've developed a program using VC++ 4.2 and MFC.  
0
Comment
Question by:markley
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
8 Comments
 
LVL 8

Expert Comment

by:MikeP090797
ID: 1310174
Are you using temporary files in your application? Do you get them via the GetTempFileName?
0
 

Author Comment

by:markley
ID: 1310175
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
0
 

Author Comment

by:markley
ID: 1310176
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
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 3

Expert Comment

by:shaig
ID: 1310177
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.
0
 

Author Comment

by:markley
ID: 1310178
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  


0
 

Author Comment

by:markley
ID: 1310179
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?
0
 
LVL 1

Expert Comment

by:IgorGrebnev
ID: 1310180
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
0
 
LVL 1

Accepted Solution

by:
IgorGrebnev earned 200 total points
ID: 1310181
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
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction: Dialogs (2) modeless dialog and a worker thread.  Handling data shared between threads.  Recursive functions. Continuing from the tenth article about sudoku.   Last article we worked with a modal dialog to help maintain informat…
Exception Handling is in the core of any application that is able to dignify its name. In this article, I'll guide you through the process of writing a DRY (Don't Repeat Yourself) Exception Handling mechanism, using Aspect Oriented Programming.
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
Come and listen to Percona CEO Peter Zaitsev discuss what’s new in Percona open source software, including Percona Server for MySQL (https://www.percona.com/software/mysql-database/percona-server) and MongoDB (https://www.percona.com/software/mongo-…

688 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question