C / C++ / MFC

CRecordset and CTime Problem

18-May-06 5:16

Hi everybody,

I have a small problem with a CRecordset. I open a dialog-box, where I set some values. When I close the dialog-box with OnOK(), I put all the values in an access-mdb using ODBC.
Right after closing my dialog-box, I need the values in the calling function. So I open my recordset again and read all the values. But the last value is missing.
When I debug my application, all values appear. When I add a button, to get the values from my database, all values appear. When the values are to be read immediately after closing my dialog-box, the last value is missing.
So I think, it is some kind of timing problem. That I read from the database, before all records are written. I tried to reopen the database in my dialogbox right after closing it and I close it again. Now all my records are there (at least mostly). But this is not really elegant.
So, is there any possibility, to wait, until the data is really written in the database after closing it, before reopening it again?

Or am I completely wrong and the problem is something else?

Juergen

e-DJ18-May-06 5:09

18-May-06 5:09

Hi everybody,

I have a big problem when using a CRecordset, that contains a CTime-object.
I use an Access-mdb via ODBC and have a table containing a date/time-row.
I can open this table using CRecordset.
I then do an Edit(), set my values and perform an Update(). Everythings works as expected.
But when I do an AddNew(), set my values and perform an Update(), a access-violation occurs. Debugging shows, that the CTime-object is called with a GetYear(). And here the GPF happens. Since this is somewhere deep inside the MFC, I can not tell, what's going wrong.

Something strange:
I have another table, containing CTime-objects and AddNew() works fine here. I have not found any special differences in my algorithms.

So, can anybody tell me the right questions to help me here?

Juergen

David Crow18-May-06 5:54

David Crow

18-May-06 5:54

In the record set's constructor, how are you initializing the CTime member?

"The largest fire starts but with the smallest spark." - David Crow

e-DJ19-May-06 2:57

19-May-06 2:57

The Class Wizard generated the constructor and as far as I can see, the CTime is not initialized.
However, before I Update() I call SetFieldNull() to initialize it.

Something special. meanwhile I don't get GPF when at least one record is in my tabel. when the table is empty, I get an GPF, but the record is written correctly. So when starting my application again, everything works.

I add the codesnippet:

Favorit.m_strFilter="User='"+myUser+"' AND Dokument='"+Number+"'";
Favorit.Open();
if(!Favorit.IsBOF())
{
    Favorit.MoveFirst();
    Favorit.Edit();
}
else
{
    Favorit.AddNew();
    Favorit.m_User=myUser;
    Favorit.m_Dokument=Number;
    Favorit.SetFieldNull(&(Favorit.m_Gelesen));
}
Favorit.m_Favorit=bChecked;
Favorit.Update();
Favorit.Close();

The function crashes, when Favorit.Update() is called after Favorit.AddNew().
Here is the declaration of the members in my Recordset:

//{{AFX_FIELD(DBFavoriten, CRecordset)
CString m_Dokument;
CString m_User;
long    m_Favorit;
CTime   m_Gelesen;
//}}AFX_FIELD

And here is the constructor:

DBFavoriten::DBFavoriten(CDatabase* pdb)
	: CRecordset(pdb)
{
	//{{AFX_FIELD_INIT(DBFavoriten)
	m_Dokument = _T("");
	m_User = _T("");
	m_Favorit = 0;
	m_nFields = 4;
	//}}AFX_FIELD_INIT
	m_nDefaultType = dynaset;
}

I don't know, what to do next. This is my first attempt at recordsets and it looks terrible.

Juergen

David Crow19-May-06 3:03

David Crow

19-May-06 3:03

Initialize m_Gelesen to CTime(NULL) in DBFavoriten's constructor.

"The largest fire starts but with the smallest spark." - David Crow

e-DJ23-May-06 5:51

Error not releasing memeory

23-May-06 5:51

Great !

This did the job.

Why does the class wizard not initialize CTime, when everything else is initialized?

Juergen

bujji_bec18-May-06 4:50

bujji_bec

18-May-06 4:50

hi Friends,

i got different problem.i made dll. after i create new project name called main (i.e new project). i tried linking implictly / explictly. every thing working Fine.

In main() i created Objects Impliectly passing the arguments.(i.e not new because implemented operater overloading.

code like this :
// after include dll
// include header files
int main()
{
char *p;
cls clsobt("./"rrr.ini);
cls1 cls1ob1 = clsobj["section"];
p=cls1ob1["varible"];
cout<

NiceNaidu18-May-06 4:58

NiceNaidu

18-May-06 4:58

bujji_bec wrote:
delete []p;

delete []p ,should always be associated with new [].
I think,that is only reason why u r getting an Error.

Can u be more specific about the Error ??

Appu..
"If you judge people, you have no time to love them."

led mike18-May-06 4:59

led mike

18-May-06 4:59

bujji_bec wrote:
delete []p; // this statement giving problem

Probably because it is wrong. The previous code gives no evidence that address is a heap address. Even if it is heap based, it was allocated by whatever clsobj is and therefore should be cleaned up by that same class rather than user code.

"What classes are you using ? You shouldn't call stuff if you have no idea what it does"
Christian Graus in the C# forum

led mike

Cedric Moonen18-May-06 5:07

Cedric Moonen

18-May-06 5:07

led mike wrote:
it was allocated by whatever clsobj is and therefore should be cleaned up by that same class rather than user code.

That doesn't make sense outside the dll context. You can allocate memory inside a class a release it outside (in the mean function for example). I agree this is ugly and to be avoided by all means but that won't produce any error.
In the context of a dll, it's different because your exe and the dll are two separate processes, so the heap managers are different. Everything that has been created by the dll has to be released by your dll and everything that has been created by your exe has to be released by your exe. If you mix that, you will get troubles Roll eyes | :rolleyes:

Cédric Moonen
Software developer

Charting control

led mike18-May-06 5:46

led mike

18-May-06 5:46

Cedric Moonen wrote:
You can allocate memory inside a class a release it outside (in the mean function for example). I agree this is ugly and to be avoided by all means but that won't produce any error.

Yes I agree. I did not mean to imply that it would break, my post was not clear in that regard.

Cedric Moonen wrote:
In the context of a dll, it's different because your exe and the dll are two separate processes, so the heap managers are different. Everything that has been created by the dll has to be released by your dll and everything that has been created by your exe has to be released by your exe. If you mix that, you will get troubles

I have no idea what you mean with that statement. You can't "mix" memory addresses across processes because you don't have access to them. Therefore you can't get that "trouble". Confused | :confused:

His post gives no indication of any remote processes. Even if there is a second process whatever address char *p; is assigned p=cls1ob1["varible"]; is in the current process anyway so I have no clue what you are talking about.

"What classes are you using ? You shouldn't call stuff if you have no idea what it does"
Christian Graus in the C# forum

led mike

Cedric Moonen18-May-06 20:25

Cedric Moonen

18-May-06 20:25

led mike wrote:
I have no idea what you mean with that statement. You can't "mix" memory addresses across processes because you don't have access to them. Therefore you can't get that "trouble".

Sorry, maybe it was not clear: your dll has its own heap manager (which manages the heap memory) and the exe has its own heap manager too. If, inside a function of your dll, you allocate memory, it will be allocated by the heap manager of your dll. If you return this pointer to your exe (simply a return from the function) and you try to delete inside your exe, the memory will be released by the heap manager of your exe, which doens't recognize it (of course, because it didn't allocate it). Thus, you got the problem.

Seing his code, if he didn't do any stupid things inside his dll (so if he simply allocate the memory as normal) that's the only thing that can cause the crash.

Cédric Moonen
Software developer

Charting control

Cedric Moonen18-May-06 5:01

Cedric Moonen

18-May-06 5:01

I don't understand what you describe. Could you be more explicit ? What are these clsobt, clobj, cls and cls1 ?? Confused | :confused:

bujji_bec wrote:
delete []p; // this statement giving problem

What problem ? You get a crash ? A compile error ? A blue cow is getting out of the screen (this one is highly improbable I think Poke tongue | ;-P

).

Anyway, what I think you are doing is using a new inside your dll (you call a function from your dll in which you allocate memory with new), you store this pointer into the variable p and then you try to free the memory. And there BANG, you get an assertion.
It is because the heap manager of your exe and of your dll are different, thus you CANNOT delete memory that has been allocated by your dll and vice-versa. To avoid this problem, use a std::string (but beware you have to link to the same run-time libraries in both of your project settings or you'll get the same problem)

Cédric Moonen
Software developer

Charting control

C^hris L^osinger18-May-06 5:10

C^hris L^osinger

18-May-06 5:10

Cedric Moonen wrote:
A blue cow is getting out of the screen (this one is highly improbable I think ).

no no. this happened to me just two days ago. i was doing a delete [] on something i had allocated with HeapAlloc then resized with _realloc. the cow was pissed, and it broke my desk.

Cleek | Image Toolkits | Thumbnail maker

Roger Stoltz18-May-06 6:17

Roger Stoltz

18-May-06 6:17

Cedric Moonen wrote:

A blue cow is getting out of the screen (this one is highly improbable I think ).

Chris Losinger wrote:

no no. this happened to me just two days ago. i was doing a delete [] on something i had allocated with HeapAlloc then resized with _realloc. the cow was pissed, and it broke my desk.

You should have derived from CGrassEater instead of CVegetarian.
Now you've made the CHolyCow angry!

It's supposed to be hard, otherwise anybody could do it!

Regarding CodeProject: "resistance is pointless; you will be assimilated"

ThatsAlok18-May-06 19:03

ThatsAlok

18-May-06 19:03

Roger Stoltz wrote:
You should have derived from CGrassEater instead of CVegetarian.Now you've made the CHolyCow angry!

Hope, he doesn't derived CHolyCow from CMenEater.....

Sorry Cedric Just Jokin!

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

cheers,
Alok Gupta
VC Forum Q&A :- I/ IV

led mike18-May-06 5:49

led mike

18-May-06 5:49

Cedric Moonen wrote:
It is because the heap manager of your exe and of your dll are different, thus you CANNOT delete memory that has been allocated by your dll and vice-versa.

What in the name of X86 are you talking about! WTF | :WTF:

"What classes are you using ? You shouldn't call stuff if you have no idea what it does"
Christian Graus in the C# forum

led mike