[Access] ODBC Inserted record niet in database?

[The_Butler]

Win XP SP 2
ISS 5.1
MS Access driver 4.00.6304.00
MS Access 2000

Ik zal proberen om het kort en krachtig te houden;

Op 1 PC draaien twee apps die beiden naar een database kijken. App 1 doet niets anders dan data dumpen in een tabel. App 2 is een webpagina die de data toont en welke onderhoud pleegt. App 2 maakt iedere drie seconde een verbinding met de databse om te kijken of er nieuwe data is.

Ik heb nu het probleem dat sommige insert queries van app 1 eens in de zoveel tijd "kwijt" raken. Volgens mijn SQL log worden ze netjes naar de database geschreven maar als ik de tabel in access open dan staat de bewuste records niet in de tabel.

Het apparte is dat als App 1 een nieuwe query verstuurd BEIDE records netjes in de database verschijnen.

Heeft iemand suggesties?

Wat ik heb gedaan:
-gezocht op tweakers/google
-windows updates
-ASP code nagekeken op connectie.Close en reccordset.Close statements

Als source code of andere info help laat het dan even weten; ik post in ieder geval de SLQ trace; de bovenste record wordt zonder problemen geschreven, de tweede record raakte tijdelijk "kwijt".

Test 1e8-150 ENTER SQLExecDirect
HSTMT 00971D98
UCHAR * 0x05D91F58 [ 122] "INSERT INTO Events (EventID,BValue,PLCtime,PLCms,PCdate,PCtime) SELECT '110','-1',#15:30:27#,'640',#2006/02/13#,#15:30:29#"
SDWORD 122

Test 1e8-150 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS)
HSTMT 00971D98
UCHAR * 0x05D91F58 [ 122] "INSERT INTO Events (EventID,BValue,PLCtime,PLCms,PCdate,PCtime) SELECT '110','-1',#15:30:27#,'640',#2006/02/13#,#15:30:29#"
SDWORD 122

Test 1e8-150 ENTER SQLGetDiagRecW
SQLSMALLINT 3
SQLHANDLE 00971D98
SQLSMALLINT 1
SQLWCHAR * 0x06D4F250 (NYI)
SQLINTEGER * 0x06D4F2B4
SQLWCHAR * 0x009723D8 (NYI)
SQLSMALLINT 2048
SQLSMALLINT * 0x06D4F2A8

Test 1e8-150 EXIT SQLGetDiagRecW with return code 100 (SQL_NO_DATA_FOUND)
SQLSMALLINT 3
SQLHANDLE 00971D98
SQLSMALLINT 1
SQLWCHAR * 0x06D4F250 (NYI)
SQLINTEGER * 0x06D4F2B4
SQLWCHAR * 0x009723D8 (NYI)
SQLSMALLINT 2048
SQLSMALLINT * 0x06D4F2A8

Test 1e8-150 ENTER SQLExecDirect
HSTMT 00971D98
UCHAR * 0x05D93548 [ 121] "INSERT INTO Events (EventID,BValue,PLCtime,PLCms,PCdate,PCtime) SELECT '110','0',#15:30:27#,'952',#2006/02/13#,#15:30:30#"
SDWORD 121

Test 1e8-150 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS)
HSTMT 00971D98
UCHAR * 0x05D93548 [ 121] "INSERT INTO Events (EventID,BValue,PLCtime,PLCms,PCdate,PCtime) SELECT '110','0',#15:30:27#,'952',#2006/02/13#,#15:30:30#"
SDWORD 121

[NMe]

Access = Office = Officesuites en -software

PW>>OFF

[Lustucru]

Ben je ze 'tijdelijk' kwijt of definitief?

[The_Butler]

Tijdelijk, na een volgende INSERT wordt de kwijtgeraakte record netjes in de tabel gezet samen met de nieuwe record. Het gebeurt trouwens alleen als er in snel tempo twee of meerdere records worden geschreven...

[The_Butler]

Ik heb het vermoeden dat mijn toppic titel mischien ietsje misleidend is; aangezien het probleem zich voordoet in het duistere gebied dat we ODBC noemen. Kan een Mod mischien de titel aanpassen naar "[ODBC Access] Inserted record niet in database?"
Vandaag ga ik trouwens proberen een andere database er aan te hangen, waarschijnlijk MySQL of de gratis versie van Microsfts SCL server.

[lier]

Kijk even of de transactie al gesloten is (als de insert onderdeel van een transactie is ?). SQL server is in meerdere opzichten een iets "mooier"product (maar MySQL voldoet ook prima !).

[The_Butler]

App 1 doet voor zover ik weet geen transacties maar schrijft direct naar de database (tenminste dat staat in de SQL trace) Maar toch ga ik even op zoek naar een manier om te zien of een db open transacties heeft.

[Lustucru]

Ik kan het zo snel niet terugvinden, maar MS heeft een lezenswaardig artikel over optimalisaties in de jet-engine. Het probleem is dat er op verschillende niveaus stevig gecached wordt: omdat Access filebased is, is het ondoenlijk om voor iedere wijziging de hele database over de lijn te sturen. Twee applicaties die dezelfde db benaderen creeren ieder hun eigen werkruimte met dit soort leuke neveneffecten.

Het goede nieuws is is dat het cachegedrag volledig instelbaar is; het slechte nieuws is dat dat niet eenvoudige materie is en dat je vaak lang zult prutsen om een optimaal comprimis te vinden tussen performance en vertragingen. Je bent idd sneller klaar met een echte client/server database.