Solved

MFC creating temporary files as a program runs?

Posted on 1997-11-18
8
294 Views
Last Modified: 2013-11-20
I've developed a program using VC++ 4.2 and MFC.  
0
Comment
Question by:markley
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
 
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
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 

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

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

This is to be the first in a series of articles demonstrating the development of a complete windows based application using the MFC classes.  I’ll try to keep each article focused on one (or a couple) of the tasks that one may meet.   Introductio…
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…
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.
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

746 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

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now