Hello, thanx for the info. I tried repairing the database thru the API as well the Tools->Database Utilities->Compact & Repair, neither is any good. Thanx for Tip 2, but that is good for checking AFTER the program, i need to make sure the data is not corrupted before this happens. This only happens when I close the application while it is listening to msgs over a TCP socket AND updating the database. If i close the sender first and close this receiver application everything is fine, otherwise, the table is empty. there was an exception in CDAOCore.cpp earlier at Line 39, but that was supposed to be a bug in MFC and I fixed it by compiling the code with MFC statically. i have been programming for a long time but this has really got me in a fix, i cannot see a pattern here at all. :confused:
samiujan
Posts
-
MFC+DAO database, 0 records inspite of data in file -
DAO+MFC console application, zero records inspite of data in filefine, that's ok but before i close it with the cross on the console or thru ctrl-c i see CDaoRecordSet::GetRecordCount() returns 11, 12, 13. When i open the mdb file in access, the table shows zero records. i am not using daoworkspace, is that the problem?
-
DAO+MFC console application, zero records inspite of data in filethanx for the reply, but if ut got rolled back, i would not see any data, if i open the file in notepad or ultra-edit, i can see my data, login_names and IP's etc. so i guess the prob is not there. thanx anyway!
-
MFC+DAO database, 0 records inspite of data in file:confused: Hi, In a nutshell: If i kill an MFC+DAO based server application while it is updating records using ctrl-c, the application exits and the database shows 0 records even though, 2 seconds ago, DaoRecordset::RecordCount() was returning 1000. It listens for messages on a socket and updates a RecordSet in table "CallLog". During update, I can see that RecordSet_for_CallLog.GetRecordCount() returns 10, 11 & 12 etc. records as messages are received over the socket, parsed and updated in the dbase. The problem occurs when I close the application midway while it is updating the Recordset. I can see that previous calls to GetRecordCount() were returning 10, 11, 12 etc. but when I open the database file in MS Access, there are no records in the table CallLog. If I open the file in Notepad, I can see the Record data in a jumbled form somewhere. So I guess, for some reason, MS Access garbles up the file while exiting, can someone tell me why? I need to handle this to avoid accidental failure. The main class is not derived from CWinApp. I call the constructor and methods directly in _tmain(). I made the application using the "Win32 Console Application" option in the New project Wizard and later checked the option for MFC support.
-
DAO+MFC console application, zero records inspite of data in fileHi, In a nutshell: If i kill an MFC+DAO based server application while it is updating records using ctrl-c, the application exits and the database shows 0 records even though, 2 seconds ago, DaoRecordset::RecordCount() was returning 1000. It listens for messages on a socket and updates a RecordSet in table "CallLog". During update, I can see that RecordSet_for_CallLog.GetRecordCount() returns 10, 11 & 12 etc. records as messages are received over the socket, parsed and updated in the dbase. The problem occurs when I close the application midway while it is updating the Recordset. I can see that previous calls to GetRecordCount() were returning 10, 11, 12 etc. but when I open the database file in MS Access, there are no records in the table CallLog. If I open the file in Notepad, I can see the Record data in a jumbled form somewhere. So I guess, for some reason, MS Access garbles up the file while exiting, can someone tell me why? I need to handle this to avoid accidental failure. The main class is not derived from CWinApp. I call the constructor and methods directly in _tmain(). I made the application using the "Win32 Console Application" option in the New project Wizard and later checked the option for MFC support. I have mainly worked in the Win32 API and on Linux, using a comiler from the commandline, so this MFC+DAO mumbo jumbo is pretty confusing. Even Charles Petzold says so :)