[ASP.NET] Meerdere database connecties

[pjvandesande]

In asp.net probeer ik te connecten naar een Access database in asp.net, dit gaat allemaal prima. Maar zodra er via een vb6 programma ook gebruik word gemaakt van die database dan vind mijn ole db het in eens ook niet meer zo fijn.

Ik krijg dan een exception met de message Could not use ''; file already in use. als ik de connection probeer te openen. Er zit dan ook inderdaad al iemand in de database, maar dit moet gewoon kunnen want het vb6 programma opent hem niet exclusief en doet op dat moment geen bewerkingen (de connection is dus idle).

De exception word omhoog gegooit in de .Open() method van een OleDbConnection object.
De connection string is voor bijde applicaties hetzelfde namelijk:

code:

Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=c:\development\TESTING\Hotel Max.mxd;
Jet OLEDB:Database Password=mijndbpassword;
Persist Security Info=False;

Meerderen connecties via asp.net lijken ook goed te gaan.

Mijn vraag is nu of het mogelijk is meerderen connecties te open, misschien doe ik iets fout?

[Not Pingu]

Een Access db wordt altijd gelocked, omdat het een bestand is en de Access driver stiekem toch wat wijzigingen uitvoert. Je kunt een Access DB dus maar door 1 user tegelijk laten uitlezen. In het geval van een webapplicatie maakt dat niet uit, omdat alle DB communicatie door de webserver user wordt geopend.

[Verwijderd]

Pleur je connectiestring van zowel je vb6 applicatie (ADO/DAO) als je ASP.NET (ADO.NET) eens hier neer...

[pjvandesande]

Verwijderd schreef op maandag 05 december 2005 @ 15:10:
Pleur je connectiestring van zowel je vb6 applicatie (ADO/DAO) als je ASP.NET (ADO.NET) eens hier neer...

Lees de TS is

[BertS]

Gunp01nt schreef op maandag 05 december 2005 @ 14:57:
Een Access db wordt altijd gelocked, omdat het een bestand is en de Access driver stiekem toch wat wijzigingen uitvoert. Je kunt een Access DB dus maar door 1 user tegelijk laten uitlezen. In het geval van een webapplicatie maakt dat niet uit, omdat alle DB communicatie door de webserver user wordt geopend.

Onzin. als het moet kun je met tientallen users een Access-db benaderen.

[elmer25]

bee-es schreef op maandag 05 december 2005 @ 16:06:
[...]

Onzin. als het moet kun je met tientallen users een Access-db benaderen.

Ja, maar dan moet je wel netjes de connectie openen als je hem nodig hebt en sluiten zodra het kan. Er is nog steeds maar 1 connectie tegelijkertijd mogelijk met Access

[BertS]

elmer25 schreef op maandag 05 december 2005 @ 16:09:
[...]

Ja, maar dan moet je wel netjes de connectie openen als je hem nodig hebt en sluiten zodra het kan. Er is nog steeds maar 1 connectie tegelijkertijd mogelijk met Access

Dat is alleen als je de db exclusief opent, anders niet. Heb het zelf gedaan in de praktijk (met enkele users en een connectie die open bleef zolang het programma in gebruik was. Ik weet het, niet netjes, maar het werkte wel uitstekend)

[pjvandesande]

bee-es schreef op maandag 05 december 2005 @ 16:06:
[...]

Onzin. als het moet kun je met tientallen users een Access-db benaderen.

Eensch!

elmer25 schreef op maandag 05 december 2005 @ 16:09:
[...]

Ja, maar dan moet je wel netjes de connectie openen als je hem nodig hebt en sluiten zodra het kan. Er is nog steeds maar 1 connectie tegelijkertijd mogelijk met Access

Nee hoor, er kunnen meerderen connecties naartoe, alleen hij pikt het niet als me webforms app connect en de winforms app ook.
Dit was ook mijn vraag, waarom dit problemen geeft en wat ik er tegen kan doen?

bee-es schreef op maandag 05 december 2005 @ 16:11:
[...]

Dat is alleen als je de db exclusief opent, anders niet. Heb het zelf gedaan in de praktijk (met enkele users en een connectie die open bleef zolang het programma in gebruik was. Ik weet het, niet netjes, maar het werkte wel uitstekend)

Nog een keer eensch!

[gorgi_19]

Puur gokwerk; de connection pool van je webapp loopt te etteren en houdt de database bezet, aangezien een connectionpool wel connecties 'behoudt'. Afsluiten is immers teruggeven aan de pool.

[pjonk]

* pjonk heeft exact dezelfde problematiek meegemaakt
Ik had IIS op mijn Windows XP machine SP2 machine draaien. Bij het maken van een database connectie wordt er altijd een .ldb lock file weggeschreven in de map van de applicatie. Ook al lees je alleen uit de database heb je toch nog schrijfrechten nodig op de folder zodat die lock file aangemaakt kan worden. Ik heb er toen voor gezorgd dat de ASPNET User schrijfrechten had op de directory waarin de database staat. Dat loste mijn probleem op, maar of het de beste oplossing is kan ik je niet zeggen.

Edit:

Puur gokwerk; de connection pool van je webapp loopt te etteren en houdt de database bezet, aangezien een connectionpool wel connecties 'behoudt'. Afsluiten is immers teruggeven aan de pool.

Dat klopt, maar dat vormt alleen een probleem als je de database exclusief opent. Je kunt overigens connection pooling uitzetten door OleDb Services=-4 toe te voegen aan je connectionstring, maar dat is om performance technische redenen niet aan te raden.

Meer info over OleDb Services:
http://msdn.microsoft.com.../oledbole_db_services.asp

[ Voor 39% gewijzigd door pjonk op 05-12-2005 17:09 ]

[pjvandesande]

pjonk schreef op maandag 05 december 2005 @ 16:57:
* pjonk heeft exact dezelfde problematiek meegemaakt
Ik had IIS op mijn Windows XP machine SP2 machine draaien. Bij het maken van een database connectie wordt er altijd een .ldb lock file weggeschreven in de map van de applicatie. Ook al lees je alleen uit de database heb je toch nog schrijfrechten nodig op de folder zodat die lock file aangemaakt kan worden. Ik heb er toen voor gezorgd dat de ASPNET User schrijfrechten had op de directory waarin de database staat. Dat loste mijn probleem op, maar of het de beste oplossing is kan ik je niet zeggen.

Kijk, top! Het probleem is helemaal opgelost, de schrijfrechten voor de ASPNET user vind ik niet echt een probleem.

pjonk schreef op maandag 05 december 2005 @ 16:57:
Je kunt overigens connection pooling uitzetten door OleDb Services=-4 toe te voegen aan je connectionstring, maar dat is om performance technische redenen niet aan te raden.

Nee, die laten we maar aan staan. Ik vind het wel een vreemd probleem, ik open hem namelijk niet exclusief.

Maargoed, ik kan in iedergeval vroeg naar huis vandaag!
* pjvandesande pakt zijn spullen en gaat naar huis

[ Voor 27% gewijzigd door pjvandesande op 05-12-2005 17:25 ]

[Not Pingu]

questa schreef op maandag 05 december 2005 @ 17:22:
Kijk, top! Het probleem is helemaal opgelost, de schrijfrechten voor de ASPNET user vind ik niet echt een probleem.

Ik maak hieruit op dat je alleen leest uit de DB, en niet schrijft?

[pjvandesande]

Gunp01nt schreef op maandag 05 december 2005 @ 17:30:
[...]


Ik maak hieruit op dat je alleen leest uit de DB, en niet schrijft?

Nee, er wordt ook geschreven. Alleen voornamelijk gelezen, het meeste invoer werk gebeurt via de winform app. Maar er kunnen online nog wel aanpassingen voorkomen.

Maar dit is niet zo'n probleem denk ik.

* pjvandesande is stiekem nog niet naar huis

[Not Pingu]

Dan ga je hoe dan ook de eerder genoemde problemen krijgen. Als zowel de webapp als de VB6 app kunnen schrijven (en in de web app heb je dat nog niet geprobeerd, anders was je wel eerder tegen de rechtenkwestie aangelopen) gaat dat botsen. Is het geen idee om de VB6 app toegang te geven via een webservice ofzo, zodat de webapp altijd verantwoordelijk is voor schrijven naar de DB?

[Verwijderd]

Ik heb dit probleem ook een keer gehad (weliswaar in combinatie met Apache/ADODB en een VB3-applicatie). Het probleem trad op na het installeren van security patch KB885835 van Microsoft van een jaar geleden. De patch verwijdert en het probleem was weg.

Bij mij was er sprake van het volgende...
Vraag de eigenschappen op van de .ldb voor het probleem. je ziet dan een tabblad security ofzo.
Vraag de eigenschappen op van de .ldb op het moment dat het probleem optreedt. de tabblad security ofzo is dan verdwenen.
Als je de database op een FAT-file systeem plaatst is het probleem ook weg

Google groups

[ Voor 31% gewijzigd door Verwijderd op 05-12-2005 22:17 ]

[pjvandesande]

Gunp01nt schreef op maandag 05 december 2005 @ 18:33:
Dan ga je hoe dan ook de eerder genoemde problemen krijgen. Als zowel de webapp als de VB6 app kunnen schrijven (en in de web app heb je dat nog niet geprobeerd, anders was je wel eerder tegen de rechtenkwestie aangelopen) gaat dat botsen. Is het geen idee om de VB6 app toegang te geven via een webservice ofzo, zodat de webapp altijd verantwoordelijk is voor schrijven naar de DB?

Waarom zou dit problemen opleveren? Er kunnen gewoon meerdere connecties opstaan?

M'n business transactions al niet me database transactions zullen me hier gewoon bij helpen door bepaalde dingen te locken indien nodig en eerst te wachten tot alles gecommit is voordat het daarwerkelijk in de databank word geworpen.

De kans dat er bewerkt word door dezelfde gebruikers is heel klein (komt in de praktijk nooit voor). Mocht het wel voor komen dan krijgt de gebruiker een message voor ze snuffert dat al ze werk voor niets is geweest en dat hij opnieuw moet beginnen.

[ Voor 2% gewijzigd door whoami op 06-12-2005 08:59 ]