MS Access of Access en SQL Server

[semicon]

Hallo,

Ik zit een beetje te dubben wat sneller zou zijn voor een niet al te zwaar systeem tot ~10 users. Ik weet niet of je qua performance er veel op vooruit gaat als ik een access frontend + een sql server zou gebruiken met "maar" ~10 users. Tijdens de tests in Access alleen (zonder koppeling met sql server) nu gaat het soms "traag" bij een grotere hoeveelheid records (500+) na een zoekactie, maar verder loopt het aardig. Ik vraag me alleen er af of het zin heeft om voor SQL Server te kiezen hierbij en of dat dan zin heeft met het aantal users.

Misschien dat iemand hier meer van weet en mij wat info/advies hierover kan geven ?

[gorgi_19]

wat zijn het voor users? concurrent users? totaal aantal users?

Wat zie je zelf als nadelen van MSDE / SQL Server Express?
Anders gezegd: Waarom zou je die niet willen gebruiken?

[semicon]

SQL Server Express heeft verder geen limitaties? Anders zag ik nogal tegen de prijs van SQL Server op.

De gebruikers zitten tegelijkertijd met ong. 10 in zelfde systeem, meestal 3 á 4 toegang in zelfde table. Ik wil gewoon niet dat het overkill gaat worden om SQL Server te gebruiken, TENzij het natuurlijk echt vele malen sneller is

[kenneth]

Het is niet zozeer sneller (in jouw geval), maar vooral betrouwbaarder. Access en concurrency gaat niet echt goed samen, MSSQL is ervoor gemaakt.

[StevenK]

Snelheid ligt vooral in hoe je de software schrijft, maar het concurrent gebruik van een MDB leidt vaak (misschien zelfs altijd) tot snelheids- en stabiliteitsproblemen.

Daarbij komt dat je met een SQL gebruik kunt maken van SP's en triggers en op die manier meer structuur in je database aan kunt brengen.

[gorgi_19]

semicon schreef op zaterdag 29 juli 2006 @ 12:59:
SQL Server Express heeft verder geen limitaties? Anders zag ik nogal tegen de prijs van SQL Server op.

De gebruikers zitten tegelijkertijd met ong. 10 in zelfde systeem, meestal 3 á 4 toegang in zelfde table. Ik wil gewoon niet dat het overkill gaat worden om SQL Server te gebruiken, TENzij het natuurlijk echt vele malen sneller is

Tuurlijk heeft het limitaties, maar het is de vraag of je er echt last van hebt

http://www.teratrax.com/a..._server_2005_express.html

[whoami]

Waarom zou je een koppeling Access / Sql Server overwegen ? Gaat dit niet de complexiteit en overhead onnodig de hoogte injagen ?
Als je al overweegt om Sql Server te kiezen, doe het dan zonder Access. SQL Server zal zeker snel genoeg zijn, 10 users zijn een eitje. (Mits goed geconfigged, goed opgezette DB, indexen en je weet wel... )

Daarbij komt dat je met een SQL gebruik kunt maken van SP's en triggers en op die manier meer structuur in je database aan kunt brengen.

of juist niet; 't is maar hoe je er tegen aan kijkt..

[kenneth]

Ik neem aan dat hij Access als frontend gebruikt.

[StevenK]

whoami schreef op zaterdag 29 juli 2006 @ 14:05:
Waarom zou je een koppeling Access / Sql Server overwegen ? Gaat dit niet de complexiteit en overhead onnodig de hoogte injagen ?

Omdat een MS Access 'project' juist specifiek bedoeld is om SQL Server als back-end te gebruiken ?

[semicon]

kenneth schreef op zaterdag 29 juli 2006 @ 14:16:
Ik neem aan dat hij Access als frontend gebruikt.

Ja, maar de kennis van mijn collega's is beperkt tot MS Access (waar ik weer minder mee werk) en het liefst werken we zoveel met Access als mogelijk (zolang het niet te veel gaat storen dat het traag wordt). De artikel tabel bevat toch tegen de 8000 records dus tis denk ik zelf net zon tussenstapje.

En we willen het idd niet te complex

[ Voor 5% gewijzigd door semicon op 29-07-2006 14:59 ]

[kenneth]

8000 is niets hoor, zelfs niet voor Access-begrippen. Het zal 'm eerder zitten in de tien gelijktijdige gebruikers, gok ik.

[StevenK]

semicon schreef op zaterdag 29 juli 2006 @ 14:59:
[...]


Ja, maar de kennis van mijn collega's is beperkt tot MS Access (waar ik weer minder mee werk) en het liefst werken we zoveel met Access als mogelijk (zolang het niet te veel gaat storen dat het traag wordt). De artikel tabel bevat toch tegen de 8000 records dus tis denk ik zelf net zon tussenstapje.

En we willen het idd niet te complex

Het probleem is niet de grootte van de database, maar de slechte locking.

[semicon]

Dus jullie denken dat ik er wel goed aan zou doen het backend gedeelte op SQL Server (enventueel zelfs Express) te laten draaien. Ik dacht zelf dat het doorgeven van SQL naar Access een vertraging zou leveren aangezien je die ODBC koppeling moet maken enzo, maar volgens mij is da door de snelheid van sql dus wel te verwaarlozen of niet van toepassing.

Ik heb net al wel de versie van express gedownload en heb nu een test database kopie hier. Ik zal het een en anders een omgooien om te testen, bedankt zover alvast

[ Voor 23% gewijzigd door semicon op 29-07-2006 16:55 ]

[kenneth]

Ik zou voor een ADP-oplossing gaan. Werken met ODBC is suboptimaal en mijn ervaringen ermee, voor wat ze waard zijn, zijn niet al te best.
Om die vertraging moet je je echt geen zorgen maken, als die al meetbaar is, dan nog is hij pas merkbaar bij databases die ietsje groter zijn

[markvt]

Ik had een access tabel met 178491 records dan ga je wat performance verlies merken, wij zijn toen overgeswitcht naar sql server express en die houd het prima vol.

[Microkid]

Access is nu eenmaal niet echt ontwikkeld voor geshared gebruik en snel raadplegen van grote tabellen. Verder loop je bij access altijd het risico op een corrupte database aangezien de foutafhandeling nu eenmaal minder is dan bij SQL. Gelukkig is er nu SQl 2005 Express (max 1 cpu, max 1GB geheugen en max 4GB database omvang). SQL is primair gemaakt voor snelle toegang, gedeeld gebruik en heeft een goede foutopvanging door de log files. SQL Express is daarmee imho toch een stuk professioneler dan acces. Gezien deze feiten en dat het gratis is, zou ik voor een SQL Express oplossing kiezen.

[StevenK]

semicon schreef op zaterdag 29 juli 2006 @ 16:54:
Dus jullie denken dat ik er wel goed aan zou doen het backend gedeelte op SQL Server (enventueel zelfs Express) te laten draaien. Ik dacht zelf dat het doorgeven van SQL naar Access een vertraging zou leveren aangezien je die ODBC koppeling moet maken enzo, maar volgens mij is da door de snelheid van sql dus wel te verwaarlozen of niet van toepassing.

In een Access Database Project gebruikt je geen ODBC, maar connect Access native met de SQL server.

[Boss]

Ik zou dus NIET voor een ADP gaan, aangezien dit niet meer wordt doorontwikkeld door MS. SQL Server 2005 heeft al niet echt lekkere ondersteuning meer hiervoor.

Maarja, als je nu MSDE gebruikt kan je op zich ook nog wel 5 jaar mee door. Maar echt toekomst-zeker is het dus niet.

[kenneth]

Zolang het bij Access blijft, is ADP nog altijd de minst slechte keuze. Dus zeggen dat je niet voor ADP moet gaan is zeggen dat hij van Access moet afstappen (moet hij ook ).

Het werkt wel met MSSQL2k5, je kan alleen niet de view/SP/function/table-designers gebruiken, maar daar heb je dan weer Management Studio voor

[Boss]

Kijk anders ook even op http://www.databaseadvisors.com/gazette/sqlexpress.htm voor meer informatie over de toekomst van ADP. Als ik dat zo lees is het in ieder geval voor mij een negatief advies richting ADP!

[kenneth]

Ja, en nu nog een keer: niet voor ADP gaan is dus niet voor Access gaan.

De verhalen over de toekomst van ADP zijn trouwens erg uiteenlopend. Op diverse blogs zeggen MSFT-ontwikkelaars dat ADP blijft, maar uit andere signalen blijkt dat MSFT meer en meer Access gaat positioneren als een oplossing voor power users en niet voor ontwikkelaars.

Hoe dan ook, ADP is inderdaad niet ideaal, maar als de optie er niet is om Access geheel te verlaten, blijft ADP de minst slechte optie.

[Boss]

kenneth schreef op woensdag 02 augustus 2006 @ 08:36:
Ja, en nu nog een keer: niet voor ADP gaan is dus niet voor Access gaan.

Access blijft een hee krachtige tool om (mits de ontwikkelaar vaardig is) om hele goede databases in te maken. Of de data via ODBC of op de ADP methode wordt gebruikt doet daar niets aan af.

Wat zijn je redenen om geen Access te gebruiken als je geen ADP kan gebruiken?

[kenneth]

In mijn beleving is Access vooral voor power users, en veel te beperkt om als serieuze ontwikkelomgeving te gebruiken, daarom kan je m.i. beter een volwaardig platform as .NET of JEE oid gebruiken. Maar dat terzijde.

Het gebruik van linked tables en pass through queries in een mdb kent behoorlijk wat problemen (zie ook KB), vooral met betrekking tot concurrencyafhandeling, datatypes, ed. Maar misschien is dat verbeterd, toen wij het rond 2002 gebruikten was het een drama, en getuige de vele KB-artikelen waren we toen niet de enige.
Wat dat betreft werken ADP's beter. Daarbij komt ingebouwde support voor SP's (met parameters) in forms, automatische mapping van je complete schema (nooit meer vergeten een tabel (opnieuw) te koppelen), een geoptimaliseerde engine.
Het grootste probleem met ADP is de toekomst, of het gebrek aan de zekerheid ervan.

[Boss]

Je voordelen voor ADP ben ik het helemaal mee eens, maar de nadelen die je beschrijft ben ik nog niet zo tegen gekomen. Alleen passthrough queries zijn inderdaad niet zo handig.

[Database freak]

Semicon, gegeven de 8000 records en een suport probleem (door het gebrek aan kennis bij je collega mbt SQL Server) zou ik hey gewoon bij Access houden.

Dat bestand van 8000 records zou je mischien zelfs wel op ram disk of flash disk kunnen zetten zodat de I/O veel sneller wordt.

nu gaat het soms "traag" bij een grotere hoeveelheid records (500+) na een zoekactie

Mischien meerdere secundary indexen aanleggen, b.v. een copie van het origineel door een dummy veld (boolean) aan de tabel toe te voegen en met dit dummy veld een tweede index te maken van de velden die ook in de eerste index zitten. Je kan natuurlijk ook nog altijd de MSDN engine (de sql 2000 versie) ergens proberen te vinden. Deze heeft op een aantal punten minder beperkingen dan de sql2005 express en sluit wellicht beter op Access aan. Je kan deze databases die op deze engine draaien geheel vanuit een Access ADP file aansturen.

[ Voor 83% gewijzigd door Database freak op 02-08-2006 09:15 ]

[Boss]

Dat bestand van 8000 records zou je mischien zelfs wel op ram disk of flash disk kunnen zetten zodat de I/O veel sneller wordt.

Dat meen je toch niet serieus? De traagheid zit hem echt niet in de snelheid van de file I/O, maar gewoon in het locking mechanisme dat Access gebruikt bij meerdere gelijktijdige gebruikers. Om nog maar te zwijgen over de technische implementatie van zoiets!

[Toink]

Staat de backend van de database (als het access is en je hebt het gesplitst) op het netwerk? De lengte van het pad heeft ZEER grote invloed op de snelheid van Access. Vorige week ben ik aan het testen geweest en het verschil tussen een directe link naar een netwerkmapping en een database ver weggestopt in een aantal niveaus diep is soms wel faktor 5! Dus als je een backend hebt, gebruik dan niet G:\map 1\submap\blabla\databases\access\vooriedereen\databasebackendvooriedereen.mdb maar hernoem de backend naar b.mdb en maak een mapped netwerkdrive aan naar precies die map zodat je bijv. Q:\b.mdb over houdt.