Problem mit Access und mehreren DB-Connections

verwendetes Datenbanksystem: Access 2007/2010

Hi,

ich arbeite zwar momentan unter VB.net, sollte aber für das Problem nicht relevant sein.
Folgendes Konstrukt:

Ich habe eine HauptConnection für die DB im MainThread. Für gewisse Aufgaben starte ich einen Backgroundworker der eine eigene Connection erhält und diese nach getaner Arbeit auch wieder aufräumt.

Im konkreten Fall erstelle ich ein größeres Dokument und speichere es im Backgroundworker in der DB und nach beenden des Workers lade ich selbiges und versuche es anzuzeigen.
Mitunter findet der Hauptthread den neuen Datensatz nicht, obwohl dieser fertig geschrieben wurde.
Wenn der selbe Code mit dem SQL-Server durchlaufen wird, gibt es keine Probleme.

Hat Access hier ein gewisses Delay bzw. wie kann ich sicherstellen, das ich mit dem Hauptthread auf den Datensatz der durch den Nebenthread geschrieben wurde zugreifen kann?

Gruß Cookiie

Hi,

ich hätte ja drauf wetten können das so eine Antwort kommt.
Als ob ich eine Wahl hätte, gewachsenes Produkt und wird vom Kunden immernoch verlangt und solange wir sagen, wir unterstützen es, wird es auch unterstützt, egal wie eklig das im Handling ist.
Neukunden wird ja sowieso grundsätzlich der SQL-Server ans Herz gelegt.

Also, ich brauch hier zumindest Lösungsideen wie man das handeln könnte.

Gruß Cookiie

Indem man schon mal keine offene globale Connection benutzt.

Der Jet Treiber der von OleDb benutzt wird ist ein ekelhaftes gerät wenn man mehr als eine Verbindung gleichzeitig offen hat.
Deshalb sollte man das tunlichst vermeiden.

Das Problem ist aber das Connectionpooling das bei Multizugriff auf mdb's nicht wirklich vorteilhaft ist.

Also schalte Connectionpooling aus und lass auf keinen Fall die HauptConnection offen.

Hi,

ja das mit dem zurückschreiben wenns grad so passt, hab ich gefühlt auch. Ist auch die einzige Stelle wo es extrem auffällt, weil erst geschrieben und im Anschluss gleich gelesen wird.

Das mit der Transaktion werd ich mal probieren. Wir haben hier schon einen vorhandenen DBLayer, kann sein das der das schon weitesgehend wegkapselt. Da bin ich aber noch nicht so tief drin im Code.

Was die generelle Verwendung angeht, eines unserer Probleme ist zB auch das manche Kunden Access verwenden und da durchaus Datenmengen zusammenkommen, die die 2GByte-Grenze von Access erreichen. Ist wie gesagt schon alles sehr an der Grenze des sinnvollen und machbaren bei Access. Aber solange der Leidensdruck noch nicht hoch genug ist under ProduktOwner nichts anderes sagt, bleibts eben bei Access + SQL Server.

Danke für die Hilfe
Cookiie

Tja, gewachsenes Produkt und im Moment nutzen es einfach noch zuviele Kunden die dann auch nicht bereit sind zu wechseln. Denke mal das wird früher oder später kommen (eher später). Wenns mal eben so ginge, wäre Access schon vor 2 MainReleases rausgeflogen.

Habs jetzt aber lösen können, ich fahr einfach in ner Schleife solange die Abfrage durch bis der Datensatz zugreifbar ist, was mitunter erst nach 5sec der Fall ist.

Gruß Cookiie