Refresh problem with CRecordset
-
Hi all, I have developed a simple database application which accesses data stored in an Access database using CRecordset. The problem is that I cannot directly see the changes that I make to the database. For example, if I insert a new record, close the recordset, open the recordset and read all records, I cannot immediately see the newly added record. In all cases, if I wait for 2-3 seconds and then read the database, I can see the newly added record. I guess that for some reason my data are not immediately stored in the database. What can I do? I have also tried with transactions (commit) but the problem remains.:confused: I thank you in advance, Christos P.
-
Hi all, I have developed a simple database application which accesses data stored in an Access database using CRecordset. The problem is that I cannot directly see the changes that I make to the database. For example, if I insert a new record, close the recordset, open the recordset and read all records, I cannot immediately see the newly added record. In all cases, if I wait for 2-3 seconds and then read the database, I can see the newly added record. I guess that for some reason my data are not immediately stored in the database. What can I do? I have also tried with transactions (commit) but the problem remains.:confused: I thank you in advance, Christos P.
I vaguely remember seeing a KB article on MSDN about this - it has to do with how Jet (which is the database engine, Access is MS's front end to the Jet database engine) caches its disk access. I suggest you look in MSDN. Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
-
Hi all, I have developed a simple database application which accesses data stored in an Access database using CRecordset. The problem is that I cannot directly see the changes that I make to the database. For example, if I insert a new record, close the recordset, open the recordset and read all records, I cannot immediately see the newly added record. In all cases, if I wait for 2-3 seconds and then read the database, I can see the newly added record. I guess that for some reason my data are not immediately stored in the database. What can I do? I have also tried with transactions (commit) but the problem remains.:confused: I thank you in advance, Christos P.
Why don't you use CDaoRecordset? Using CRecordset/ODBC with Access is like, well, sucking the cake through straw :) Tomasz Sowinski -- http://www.shooltz.com
*** Si fractum non sit, noli id reficere. ***
-
Why don't you use CDaoRecordset? Using CRecordset/ODBC with Access is like, well, sucking the cake through straw :) Tomasz Sowinski -- http://www.shooltz.com
*** Si fractum non sit, noli id reficere. ***
If you're going away from ODBC you should - at least in my mind - go to OLEDB (or ADO if you're a pussy). DAO is legacy (but so is MFC, or at least that's what everybody asks every time there's a new VC version). Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
-
If you're going away from ODBC you should - at least in my mind - go to OLEDB (or ADO if you're a pussy). DAO is legacy (but so is MFC, or at least that's what everybody asks every time there's a new VC version). Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
Steen Krogsgaard wrote: If you're going away from ODBC you should - at least in my mind - go to OLEDB It depends on the size/complexity of the application (and prospects of moving from Jet to MSSQL, for example). I've got the impression that OP's app is quite simple and he's just entering the area. In this case, going OLEDB way with ATL templates would be an overkill IMHO. Tomasz Sowinski -- http://www.shooltz.com
*** Si fractum non sit, noli id reficere. ***
-
Steen Krogsgaard wrote: If you're going away from ODBC you should - at least in my mind - go to OLEDB It depends on the size/complexity of the application (and prospects of moving from Jet to MSSQL, for example). I've got the impression that OP's app is quite simple and he's just entering the area. In this case, going OLEDB way with ATL templates would be an overkill IMHO. Tomasz Sowinski -- http://www.shooltz.com
*** Si fractum non sit, noli id reficere. ***
Of course, you're right, OLEDB/ATL is not easy and may be overkill. And my comment about ADO was just kidding - I think ADO is good for simple DB apps with low requirements to performance and amount of data. I just don't think that DAO is easier than ADO (it's even the same three letters, just shuffled around ;-) ), and I don't think ODBC is easier than any of them. But if the app has any seriousness ;P in it it should use OLEDB/ATL (or a native interface) Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
-
Of course, you're right, OLEDB/ATL is not easy and may be overkill. And my comment about ADO was just kidding - I think ADO is good for simple DB apps with low requirements to performance and amount of data. I just don't think that DAO is easier than ADO (it's even the same three letters, just shuffled around ;-) ), and I don't think ODBC is easier than any of them. But if the app has any seriousness ;P in it it should use OLEDB/ATL (or a native interface) Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
Steen Krogsgaard wrote: I just don't think that DAO is easier than ADO I disagree - it's waay easier to use CDaoXXX classes which are integral part of MFC than to #import ADO stuff. For simple app accessing .mdb files it's more than enough. Steen Krogsgaard wrote: should use OLEDB/ATL (or a native interface) You mean Jet native interface? This would kill any chances of easy migration to real SQL database. Long time ago when I was actually working with OLEDB we had a quite compilcated program which could easily run on Jet or MSSQL without recompiling. Tomasz Sowinski -- http://www.shooltz.com
*** Si fractum non sit, noli id reficere. ***
-
Steen Krogsgaard wrote: I just don't think that DAO is easier than ADO I disagree - it's waay easier to use CDaoXXX classes which are integral part of MFC than to #import ADO stuff. For simple app accessing .mdb files it's more than enough. Steen Krogsgaard wrote: should use OLEDB/ATL (or a native interface) You mean Jet native interface? This would kill any chances of easy migration to real SQL database. Long time ago when I was actually working with OLEDB we had a quite compilcated program which could easily run on Jet or MSSQL without recompiling. Tomasz Sowinski -- http://www.shooltz.com
*** Si fractum non sit, noli id reficere. ***
Tomasz Sowinski wrote: You mean Jet native interface? No, I actually ment native interfaces to databases that are more enterprise-minded (like SQL Server, DB2, Oracle, MySQL etc). I'm not even sure there is a native Jet interface? I guess DAO is the closest you get to a native Jet interface. And native interfaces should only be used if performance is more important than portability. That's what I like about OLEDB - you get a reasonable performance and a high degree of protability. Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
-
Hi all, I have developed a simple database application which accesses data stored in an Access database using CRecordset. The problem is that I cannot directly see the changes that I make to the database. For example, if I insert a new record, close the recordset, open the recordset and read all records, I cannot immediately see the newly added record. In all cases, if I wait for 2-3 seconds and then read the database, I can see the newly added record. I guess that for some reason my data are not immediately stored in the database. What can I do? I have also tried with transactions (commit) but the problem remains.:confused: I thank you in advance, Christos P.
This may depend on the version of the OS and/or the version of the ODBC driver... but check to see if you can set the buffer size. I think I ran into something like when moving one of my application to ME and I may have been moving to a newer ODBC driver at the same time (sorry I don't have details on version number just now). Anyway I think there was something that set the buffer to 1024 and I changed it to 256 (or something like that).