Access als database, slecht ?

[Erhnam]

Wij zijn met een opdracht bezig en staan voor de keuze welk type database we gaan gebruiken. We hebben een beetje ervaring met access. Het gaat om een tracking systeem waarbij we distributie processen in kaart proberen te brengen. Tevens komt er in de database producten informatie te staan. Meerdere gebruikers werken met het systeem en hebben allemaal rechten en inlog tot het systeem. Hoe goed is deze opdracht te maken met access. Ik weet dat het eerste probleem de gebruikersrestricties zijn die je niet kan aangeven. Maar dit is bv ook met asp op te lossen. Welke na- of voordelen heeft Access nog meer. Is Access uberhaupt wel geschikt voor deze opdracht ?

[Verwijderd]

Access is niet gebouwd om met een groot aantal mensen tegelijk in een database te werken, wil je dit wel moet je voor een schaalbaarder pakket kiezen (sql server, oracle, vaak zijn postgres en mysql ook opties). Het schijnt dat een access database niet veel groter dan een aantal gb mag zijn wil het nog een beetje aanvaardbaar snel en betrouwbaar werken.

[Pogostokje]

Access kan max 255 gebruikers (sessies) tegelijk aan, maar dat is een theoretisch maximum en de praktijk ligt veel lager. Als je actief bezig bent zit je met 30 aan de max.
Gebruikersrectricties kan je wel degelijk aangeven binnen Access, en dat ook door laten lopen in ASP hoewel je er ook voor kan kiezen die restricties in ASP in te bouwen, dan ben je flexibeler maar moet je wel extra opletten dat die site niet te hacken valt.
Een Access database kan ook wel redelijk groot worden, maar bij >10MB merk je wel dat het echt van je netwerksnelheid e.d. gaat afhangen of het nog een beetje wil werken.

Ik heb zelf ooit in een studententijd een Access database gemaakt van 60MB groot waar tegelijk 30 tot 40 man heel actief in zaten te werken. Dat ging nog net goed, maar als 1 zijn PC niet goed afsloot had je meteen corruptie enzo. De fault tolerance bij Access is erg laag: het is een normaal bestand, als dat niet meer goed is dan ben je ALLES kwijt.

Ik zou je daarom willen aanraden om, als je serieus bezig bent, toch te kijken naar SQL Server of Oracle en dat soort 'echte' databases.

[Verwijderd]

Wat is je budget?

[ACM]

Het best is het natuurlijk als je het een beetje portable houdt, mocht access dan niet voldoen dan kan je waarschijnlijk zonder veel moeite overstappen op MSSQL.

Nadelen die ik van access gehoord heb zijn de schaalbaarheid (hoe reageert het als er veel gebruik van gemaakt wordt) en dat soort zaken.

[Erhnam]

Verwijderd schreef op 05 oktober 2002 @ 20:02:
Wat is je budget?

We willen de kosten tot een minimum beperken. Maar de klant moet wel een betrouwbaar pakket krijgen waar ook rekening gehouden moet worden bij evt uitbreidingen in de toekomst. Eventuele kosten van een pakket zoals MS sql kunnen altijd besproken worden.

[Pogostokje]

Eventuele kosten van een pakket zoals MS sql kunnen altijd besproken worden.

Als het bedrijfskritisch is: lees mijn posting van zojuist en dan vooral het stukje over de fout bestendigheid.
De prijs van MS SQL (of anderen, bv. MySQL is gratis...) kan wel of niet hoger zijn dan de prijs van een verdwenen database. Dat is een simpele rekensom.

[Erhnam]

Beetje info over wat er mee gedaan moet worden:

Er komen bv al 100-en ( misschien wel niet meer dan 1000 ) productsheets in te staan met plaatjes en product specs. Tevens gaan er mensen in het buitenland mee werken ( mensen in China gaan nieuwe producten invoeren en bewerken de tracking van verzonden producten )

[Verwijderd]

Adhv je bovenstaande omschrijving kan ik toch wel met enige zekerheid zeggen dat een enterprise level database wel een welkome aanwinst zou zijn.

In eerste instantie blijft het bij een label van een productsheet, waarbij de productsheet als een longtext/blob veld wordt opgeslagen. Vervolgens komt de E-business manager van de afdeling en die wil alle data afzonderlijk gaan groeperen in de database, en moet men kunnen zoeken op dit item op die plek.

Zodoende kan zeker al met een product-sheet achtige inval de database tot immense grootte groeien. Op dat ogenblik worden zaken als indexering, transactions, etc. alweer een stuk belangrijker. Veelal zaken die alleen in de enterprise database oplossingen zijn terug te vinden, en kunnen zorgen (lees "kunnen") voor bedrijfszekerheid.

Misschien dat je zelfs eens moet kijken naar een Document Management oplossing.

[Pogostokje]

Erhnam schreef op 05 oktober 2002 @ 20:12:
Beetje info over wat er mee gedaan moet worden:

Sjees .... en dan DENK JE NOG NA over Access???

Dit vereist heel wat meer dan een normale database. Dit klinkt idd als een enterprise oplossing die jij zoekt op dedicated servers. Dan ga je toch niet met een huis-tuin-keuken database klooien??? Deze data is heel veel arbeid waard, en arbeid is duur. Dus tenzij die data heel snel opnieuw te reproduceren is in het geval van een databasecrash denk ik dat je je lat toch wat hoger moet leggen...

Had dat meteen uitgelegd, had je een hoop replies gescheeld.

[ErikRo]

Pogostokje schreef op 05 oktober 2002 @ 20:00:
Access kan max 255 gebruikers (sessies) tegelijk aan, maar dat is een theoretisch maximum en de praktijk ligt veel lager. Als je actief bezig bent zit je met 30 aan de max.
Gebruikersrectricties kan je wel degelijk aangeven binnen Access, en dat ook door laten lopen in ASP.
Ik heb zelf ooit in een studententijd een Access database gemaakt van 60MB groot waar tegelijk 30 tot 40 man heel actief in zaten te werken. Dat ging nog net goed, maar als 1 zijn PC niet goed afsloot had je meteen corruptie enzo. De fault tolerance bij Access is erg laag: het is een normaal bestand, als dat niet meer goed is dan ben je ALLES kwijt.

Bedankt voor de tip, ik ben zelf met iets kleins bezig (invoer/raadpleegDB, met alleen naw gegevens en afspraken).
Daar zouden wel 80 man tegelijk in kunnen raadplegen, zeker als niet iedereen uit het programma gaat zodra ze klaar zijn.

Uitgaande dat 255 het max was verwachte ik geen problemen.
Maakt het nog wat uit als het een losse VB6 app is die zijn gegevens opslaat in een apart Acces97MDB bestand?

Even uit nieuwsgierigheid hoe loste je die corruptie op? Die paar keer dat iemand autorepair of zoiets probeerde, hielp het niets en konden we de DB weggooien.

[Pogostokje]

Uitgaande dat 255 het max was verwachte ik geen problemen.
Maakt het nog wat uit als het een losse VB6 app is die zijn gegevens opslaat in een apart Acces97MDB bestand?

Ja, dat maakt wel iets uit. Je zal dan niet snel een corruptie krijgen als iemand zijn PC uitgooit, tenzij dat midden in een query is. Daar gaat Access gewoon heel slecht mee om. Als de frontend niet in Access zelf staat dan denk ik dat je wel iets betere specs kan verwachten, maar Access is niet gemaakt voor high-performance. Je zal toch een traag ding overhouden als er een hoop gebruikers inzitten. Probeer maar eens 30 spannende queries in een redelijk grote access database tegelijk uit te voeren, dan merk je wat ik bedoel. Wil je performance dan moet je gewoon naar 'echte' databases over, die zijn gemaakt voor performance en bieden ook een hoop middelen om de performance te tunen richting je eigen wensen en hardware.

Even uit nieuwsgierigheid hoe loste je die corruptie op? Die paar keer dat iemand autorepair of zoiets probeerde, hielp het niets en konden we de DB weggooien.

Toch een autorepair doen. Dat helpt vaak. En maak copieen, elke dag zodat je desnoods iets terug kan zetten. Erg stabiel is het niet, maar gelukkig heeft autorepair mij heel erg geholpen altijd. Achteraf gezien had ik dat nooit op een Access systeem moeten bouwen natuurlijk, maar ja ... in je studententijd denk je dat je weet wat wijsheid is.
Een gratis MySQL of niet-gratis MS-SQL of Oracle server werkt ook prima samen met Access en VB, en alle drie waren ze ook beschikbaar bij dat bedrijf. Maar gelukkig is het altijd goed gegaan.

[RedRose]

Een voorbeeldje uit de praktijk:
Wij draaien hier een Access database met een declaratie/facturerings systeem, waarin gemiddeld dagelijks zo'n 25 man continue in zitten te werken. De database met de gegevens zelf staan op een server en de hulptabellen en de frontend staan bij de gebruikers lokaal. De boel is aangeleverd door een externe consultant die her en der wat VB-scriptjes had geript en daar een 'leuk' maatwerk-systeem van had gebouwd.

Wat we nu al merken is dat er bij ongeveer 20 gebruikers tussen de 10 en 15 file-locks optreden, waardoor de database steeds inconsistenter wordt. Als beheerder heb je er dus veel werk aan om al de tabellen op te schonen en netjes te houden.

Daarnaast is het datamodel niet echt te optmaliseren met Access. De relaties tussen de tabellen lijken meer op een spinneweb dan op een goed gestructureerd model. En dat is niet goed voor de performance, omdat je simpelweg meer queries moet doen om informatie te krijgen ten opzichte van een standaard SQL-server.

Omdat je in Access werkt (of de Access Run-time environment gebruikt), leg je jezelf ook nogal wat beperkingen op bij het ontwerpen van je interface of front-end. En ja, er bestaat zoiets als gebruikersbeheer in Access, maar echte beveiliging heb je er niet mee, terwijl je dat in veel gevallen wel zou willen.

Ik zou gaan voor een simpele stand-alone VB-applicatie met daarachter een MS-SQL server. Mocht het budget er niet zijn, kies dan voor een webinterface (PHP/ASP) met daarachter een MySQL (of liever: PostgreSQL) -database.

[Verwijderd]

Je kan access gewoon als frontend blijven gebruiken, en de tabellen via ODBC ophalen uit een 'echte' database server (bv. PosgreSQL). Dat houd het flexibel : je kan altijd je frontend of je database server veranderen zonder dat de 'andere' component meteen mee moet wijzigen.

[Erhnam]

Verwijderd schreef op 06 oktober 2002 @ 15:39:
Je kan access gewoon als frontend blijven gebruiken, en de tabellen via ODBC ophalen uit een 'echte' database server (bv. PosgreSQL). Dat houd het flexibel : je kan altijd je frontend of je database server veranderen zonder dat de 'andere' component meteen mee moet wijzigen.

Hoe bedoel je dit precies ? Zou je wat meer uitleg kunnen geven ?

[Verwijderd]

Met Access heb ik een vuistregel: Access is een simpel pakket voor het maken van simpele dingen. Als ik dus iets complexer zou moeten maken zou ik persoonlijk al snel aan een alternatief gaan denken.

[Verwijderd]

Erhnam schreef op 06 oktober 2002 @ 15:41:
[...]


Hoe bedoel je dit precies ? Zou je wat meer uitleg kunnen geven ?

Wat hij bedoelt is dat de data extern wordt opgeslagen. In een database pakket wat bekend is met grote hoeveelheden gegevens, en ingebouwde beveiligingen heeft om te voorkomen dat data kwijt raakt of geen relatie meer met elkaar heeft.

Access wordt dan in een dergelijke geval gebruikt als interface welke alleen commando's geeft aan de database server.

In mijn oogopzicht zou ik dan zeggen, skip access, maak de userinterface in een daarvoor bedoeld (programmeer)pakket. Dan heb je wat meer kracht en functies beschikbaar voor wat je wilt gaan doen met de data.

[Erhnam]

MS SQL Server kost dat daadwerkelijk ongeveer 7000 euro.. Ik dacht dat het rond de 1000 euro lag.. Heb je geen goedkopere edities ? Ik heb die 180 dagen trial even getest en bekeken ! Ziet er zeer goed uit en werkt bv perfect samen met dreamweaver.

[Verwijderd]

't duur maar dan heb je ook wat.... je moet voor zo'n oplossing echt aan een RDBMS

[ACM]

Erhnam schreef op 06 oktober 2002 @ 18:55:
Ik heb die 180 dagen trial even getest en bekeken ! Ziet er zeer goed uit en werkt bv perfect samen met dreamweaver.

SQL Server samenwerken met dreamweaver
Denk het dus niet, andersom misschien wel... Maar ga er maar niet van uit dat er bij MS SQL Server veel moeite is gedaan voor de support voor MSSQL die dreamweaver heeft. Uiteraard heeft Microsoft een programmeerinterface aangeleverd, maar dat kan elke developer gebruiken

Gaarne de redenatie dus omdraaien:
Dreamweaver zal dan perfect met MSSQL server werken
Maar ik gok dat het ook perfect met Oracle, DB2 e.v.a. samenwerkt...

[smaij]

* smaij is naar een seminar van PHP/MYSQL met dreamweaver geweest.. opzich wel leuk product, alleen heeft het net zoals vele andere codegeneratoren beperkingen

daarnaast effe ontopic. SQL Server voor 7000 euro is niet veel geld als ik zie wat je ermee wilt.. het gaat om een systeem wat over de hele wereld goed moet functioneren en waar 'veel' gebruik van gemaakt gaat worden.

je zou ook naar PosGreSQL kunnen kijken

[Verwijderd]

Ga voor zo'n project alsjeblief niet zitten vrutten met Access. Neem een goede relationele database met goede recovery mogelijkheden, schaalbaarheid en performance.

Als je het in de Microsoft hoek wilt houden is MS SQL server 2000 op een Windows2000 een goede keus.
Als het qua stabiliteit en robuustheid echt goed moet zijn neem dan een oplossing van Oracle ism. Linux ofzo. IBM kan je daarbij helpen.

Maar nogmaals. Blijf bij dat speelgoed wannabee database van een Access af. Het is namelijk "juist niet" de argumenten die ik al opgaf.

[Verwijderd]

Verwijderd schreef op 06 oktober 2002 @ 15:39:
Je kan access gewoon als frontend blijven gebruiken, en de tabellen via ODBC ophalen uit een 'echte' database server (bv. PosgreSQL). Dat houd het flexibel : je kan altijd je frontend of je database server veranderen zonder dat de 'andere' component meteen mee moet wijzigen.

Dat vindt ik een slecht idee: 't hele zootje wordt daar vreselijk traag van. Bovendien: als je toch ODBC gaat gebruiken, maak dan gewoon een DSN aan en koppel je client direct naar de database.

(edit)->
Ik zou zeggen: gebruik gewoon meteen een goed pakket zoals Oracle, SQL server, etc. anders vraag je om problemen.
(/edit)

[Verwijderd]

Gewoon lekker access gebruiken, de backend op de server plaatsen, een runtime op iedere client pc met daarop de frontend. Maak een aparte .mdw file aan (dus niet de system mdw) en stop daar alle user accounts in (en daarna de frontend opstarten met de juiste mdw file). En iedere keer bij het afsluiten automatisch laten comprimeren (zowel backend als frontend). Dan kun je met access best snel een krachtig systeem bouwen.

[Verwijderd]

Acces is voor thuisgebruik en kleine bedrijven. Wil je echt iets bouwen, gebruik MySQL.

MultiPlatform, dus zowel Linux als MS, enz.

[Verwijderd]

Er komen bv al 100-en ( misschien wel niet meer dan 1000 ) productsheets in te staan met plaatjes en product specs. Tevens gaan er mensen in het buitenland mee werken ( mensen in China gaan nieuwe producten invoeren en bewerken de tracking van verzonden producten )

Gewoon lekker access gebruiken]

Wil je echt iets bouwen, gebruik MySQL

Nix access / MySQL / etc. -> gewoon meteen een echt pakket gebruiken.

[Creepy]

Verwijderd schreef op 07 oktober 2002 @ 08:44:
[...]


[...]


[...]


Nix access / MySQL / etc. -> gewoon meteen een echt pakket gebruiken.

Geef ook meteen ff aan welk pakket, en PLEASE... onderbouw die zooi ff... quoten en daarna zeggen dat je een "ECHT" pakket moet gaan gebruiken is geen onderbouwing. Wat is een "echt" pakket? Oracle bijv? Daar hangt dan ook een "ECHTE" prijs aan.

Uit persoonlijke ervaring kan ik zeggen dat access voor een hoop goed gebruikt kan worden. 100'en (en zelfs duizenden) produkten opslaan is niks.. ook niet voor access.. dat gaat prima. Je kan een probleem krijgen als je tegelijk met meerdere mensen gaat zitten bewerken in de DB (lost updates etc.). Met meerdere mensen tegelijk LEZEN is helemaal geen probleem.

[Verwijderd]

Geef ook meteen ff aan welk pakket, en PLEASE... onderbouw die zooi ff... quoten en daarna zeggen dat je een "ECHT" pakket moet gaan gebruiken is geen onderbouwing. Wat is een "echt" pakket? Oracle bijv? Daar hangt dan ook een "ECHTE" prijs aan.

Wel ff het draadje lezen voor je zo begint...

[Creepy]

Verwijderd schreef op 07 oktober 2002 @ 08:17:
[...]


Dat vindt ik een slecht idee: 't hele zootje wordt daar vreselijk traag van. Bovendien: als je toch ODBC gaat gebruiken, maak dan gewoon een DSN aan en koppel je client direct naar de database.

(edit)->
Ik zou zeggen: gebruik gewoon meteen een goed pakket zoals Oracle, SQL server, etc. anders vraag je om problemen.
(/edit)

Deze quote van jezelf bedoel je????
Ik zelf mis hier ook nog enige onderbouwing hoor.. zoals welke problemen, en waarom je precies voor welk pakket zou kiezen. Aan Access zitten ook bepaalde voordelen (relatieg simpel, goedkoop) maar daar hoor je weer niemand over
(access... baaaadddd!)

_{Ja ik had de draad al gelezen}

[Verwijderd]

Zelf gebruik ik zowel access als mySQL, informix, sql server en oracle.

Nadelen van access vindt ik:
- traag bij grotere hoeveelheden gebruikers
- database raakt snel corrupt, lockfiles worden bij grote hoeveelheden gebruikers soms niet goed aangemaakt/bijgewerkt/afgesloten
- gebruikersbeheer is lastiger dan bij sql server/oracle/etc
- ontbreken van bepaalde mogelijkheden mbt diagrammen, views, stored procedures etc
- stabiliteit laat soms te wensen over

Uiteraard heeft access bepaalde voordelen (b.v. simpel en goedkoop maar ook de b.v. de eenvoudige report generator) maar dat uit zich met name in het voorkomen van bovenstaanden nadelen.

Mijn punt is: voor de benodigde schaalgrootte en toegangkelijkheid vindt ik access minder geschikt.

[Creepy]

Dank

[Pogostokje]

Wat we nu al merken is dat er bij ongeveer 20 gebruikers tussen de 10 en 15 file-locks optreden, waardoor de database steeds inconsistenter wordt. Als beheerder heb je er dus veel werk aan om al de tabellen op te schonen en netjes te houden.

Ik moet hier toch even op reageren... want als dit gebeurt dat is de database gewoon niet goed opgezet.

Daarnaast is het datamodel niet echt te optmaliseren met Access. De relaties tussen de tabellen lijken meer op een spinneweb dan op een goed gestructureerd model.

Hiervoor geldt hetzelfde ... als je een goed database model opzet kan je dat prima vertalen in een model in Access. Ik hoop dat je je vergelijking met een 'spinneweb' niet maakt aan de hand van het plaatje wat je op je scherm ziet wals je kiest voor het relatieoverzicht... want dat is een layout kwestie en heeft niks te maken met de werkelijke structuur.

En dat is niet goed voor de performance, omdat je simpelweg meer queries moet doen om informatie te krijgen ten opzichte van een standaard SQL-server.

.... en met mijn opmerkingen is dit dus helaas ook niet waar.


Als je dit echt vindt ben ik heel benieuwd naar wat concrete voorbeelden.

En ja, er bestaat zoiets als gebruikersbeheer in Access, maar echte beveiliging heb je er niet mee, terwijl je dat in veel gevallen wel zou willen.

De beveiliging is toch wel redelijk echt, al is alles natuurlijk te hacken als je toegang hebt tot de juiste tools.
Je kan binnen Access goed werken met restricties op tabellen en views. Dat samen zorgt voor een redelijk sterk beveiligingsplan.

[Brakkie]

Zo veel is dat toch niet. 1000 product sheets in een database. Of moet er nog veel meer in komen?
Als dit het enige is wat je op wilt slaan lijkt MySQL al een prima oplossing aangezien het gratis is en jij niet teveel wilt uitgeven. Misschien zie ik het verkeerd hoor maar waarom is er zo'n heavy database nodig om 1000 product sheets op te slaan.

[Verwijderd]

Ik zou zeggen ontwerp de boel gewoon in Access. Plaats de tabellen in een apparte MDB. Zorg voor een goed ontwerp. Kijk of alles naar behoren werkt. Is het voldoende hou access...is het te traag vervang de aparte MDB met tabellen voor een groter Database pakket.

Dus eerst maar eens bekijken wat voor jou snel genoeg is voordat je direct Access aan de kant schuift...

[smaij]

Ik zou geen acces nemen (bovenstaande reden, plus genoeg alternatieven), maar MySQL is toch wel goed genoeg hiervoor hoor. en heeft een prima ondersteuning voor alle platformen, bedoeld voor internet, maar ook prima te gebruik met MyODBC koppelingen.

[jochemd]

Mensen in China gaan hem bewerken? Heb je al nagedacht over de noodzaak voor ondersteuning van verschillende collations en charsets? Als dat noodzakelijk is valt er namelijk wel het een en ander aan opties af.

[Erhnam]

jochemd schreef op 07 oktober 2002 @ 14:13:

Mensen in China gaan hem bewerken? Heb je al nagedacht over de noodzaak voor ondersteuning van verschillende collations en charsets? Als dat noodzakelijk is valt er namelijk wel het een en ander aan opties af.

De database wordt gewoon in de engelse taal ontworpen. De chinezen die er mee gaan werken spreken redelijk engels. Onze taak is een systeem op poten te zetten waar een aantal van hun 1000-en sheets in komen te staan ter informatie voorziening op het internet. Tevens gaan de chinezen nieuwe sheets invoeren ( goedkope arbeidskracht ) De sheets bevatten naast tekst, ook plaatjes en documenten die er aan gekoppeld zijn.

Verder wordt er een tracking systeem aangekoppeld. Zodra de producten de fabrieken ( ook in china ) uit zijn, logt een chinees in op de website en veranderd de status van het product ( in bv verzonden ). Deze interactie vindt meerdere keren plaats.

Tevens is er een koppeling tussen tracking en sheet. Iemand kan met een paar klikken een tracking opvragen en product informatie opvragen ( deze zijn gekoppeld met de sheets ).

Het is niet zo dat er dagelijks 10-tallen mensen met het systeem zitten te werken. het zal zich beperken tot af en toe de status veranderen van producten die in het distributie-process zitten tot het opvragen van de status. Verder worden er een paar keer per week wat nieuwe sheets toegevoegd en zullen de sheets wat vaker worden uitgelezen. In de database komt ook product specifieke informatie te staan ( deze is niet voor iedereen die inlogt toegankelijk ).

De hele 'applicatie' ( als je daar van mag spreken ) is webbased dus. Het geheel wordt in Nederland gehost ? Maakt Access of SQL wat uit met de snelheid. Dus meer transmissie met Access over het internet dan SQL ?

De opdracht eindigd met mensen die naar china gaan om de chineze zo ver te krijgen dat ze echt met het systeem gaan werken en dat het echt in gebruik genomen wordt.

Als laatste zou het lekker zijn als het werkt en gewoon doet waar het voor moet staan. Aangezien het een 'soort' stage opdracht is zou het lekker zijn dat als als er een paar naar china gaan dat het systeem er dan niet 3 maal per week uitklapt. Betrouwbaarheid speelt dus wel degelijk een rol! Ook moet het beheren redelijk goed te doen zijn. Er zijn afspraken gemaakt dat na onze stage er een 'redelijk support' gegeven blijft worden maar een vast systeembeheer zit niemand van ons tijdens onze studie nog op te wachten.

[raptorix]

Verwijderd schreef op 07 oktober 2002 @ 08:35:
Acces is voor thuisgebruik en kleine bedrijven. Wil je echt iets bouwen, gebruik MySQL.

MultiPlatform, dus zowel Linux als MS, enz.

Gebruik dan bijvoorbeeld SapDB, ook gratis, mysql is nou niet iets wat ik in een bedrijfsomgeving zou gebruiken.

[GraasGast]

Als je voor (erg) weinig geld een acceptabele oplossing wil, lijkt PostgreSQL me de enige optie...

[Morpheus_at_work]

Verwijderd schreef op 05 oktober 2002 @ 20:02:
Wat is je budget?

single sql server licentie slik 39.000 oude guldens , denk dat het buiten budget valt
goedkoopste oplossing is mysql

[raptorix]

Morpheus_at_work schreef op 08 oktober 2002 @ 14:00:
[...]


single sql server licentie slik 39.000 oude guldens , denk dat het buiten budget valt
goedkoopste oplossing is mysql

wanneer gaan bepaalde mensen nou eens verder kijken als hun neus lang is, daarnaast kan je bijvoorbeeld ook voor rond de 1000 piek een sqlserver 7 licentie aanschaffen, overigens is de prijs die je noemt ook niet juist maar dat terzijde.