Beste keuze voor automatisering

[f.heinen]

Op mijn bedrijf hebben we al 5 jaar iemand in dienst (full-time) die met access&VBA het bedrijf automatiseerd. Vraag nu niet waarom MS acces want deze keuze is gemaakt en niet meer terug te draaien.
Het gaat hier op van allerlei applicaties, van uren administratie tot engineering modules, van offerte module tot inkoop gegevens. We werken met zo'n 50 mensen bijna full time met deze modules.
Het gebruik van access in een multi user omgeving geeft een (aantal) nadelen (op gebruikersniveau).
Vooral snelheid, koppelbaarheid van de modules, beveiliging, live screen updating en multi users access zijn problemen.

Naar mijn inziens is MS Access als basis niet de beste keuze geweest, vanuit de huidige positie bekeken.

Wat ik nou graag zou willen weten is wat jullie denken wat de beste keuze is voor de toekomst. Waarbij je het volgende in acht moet nemen:
- Alle MS access modules moeten blijven werken.
- De server is een windows server.
- Er is geen linux kennis.
- Multi user omgeving
- Programmeeer snelheid moet minstens even snel zijn dan MS Access.
- Optioneel: web access.
- Upgradebility moet beter zijn dan MS Access (nou moet dit geen probleem zijn wat MS Access/VBA upgraden is een ramp!)

[Swerfer]

Ik zou in zo'n geval kiezen voor SQL server met Visual Basic .net applicaties ivm de aanwezige kennis van VBA, en asp.net (ook weer visual basic) voor web applicaties.

De acces database zou geimporteerd kunnen worden in SQL server, maar de VBA moet flink aangepast worden om er visual studio applicatie(s)/subroutines van te maken.

[JKVA]

Het is maar net hoeveel tijd je kwijt wilt zijn met het leren van een nieuwe taal, anders zou ik voor een web-based .NET oplossing gaan met SQL server.

Je moet wel zorgen dat je je access databases goed migreert naar SQL server, maar dat mag geen probleem zijn mijns insziens. Importeren zal denk ik niet lukken, aangezien er wel wat schemawijzigingen bij komen kijken denk ik.

Je moet alleen even (serieus wat) tijd uittrekken voor het leren van .NET en dan ook meteen maar C#, ben je meteen weer voor een tijdje klaar met upgraden.

[Swerfer]

JKVA schreef op zondag 23 juli 2006 @ 11:12:
Je moet alleen even (serieus wat) tijd uittrekken voor het leren van .NET en dan ook meteen maar C#, ben je meteen weer voor een tijdje klaar met upgraden.

Waarom meteen C#? VB is bijna net zo krachtig in .NET, en aangezien er al gewerkt wordt met VBA is de overgang naar VB.NET veel gemakkelijker dan het leren van een andere programmeertaal.

[pacificocean]

Volgens mij moet je jezelf de vraag stellen wat maakt onze situatie zo uniek dat we geen standaard applicatie kunnen gebruiken.

[Not Pingu]

Swerfer schreef op zondag 23 juli 2006 @ 11:28:
[...]

Waarom meteen C#? VB is bijna net zo krachtig in .NET, en aangezien er al gewerkt wordt met VBA is de overgang naar VB.NET veel gemakkelijker dan het leren van een andere programmeertaal.

Da's niet waar. VBA en .NET zijn compleet andere ontwikkelplatformen. Je zult weinig van je VBA kennis mee kunnen nemen naar VB.NET, behalve dan dat je het taaltje kent. Kennis van het onderliggende platform is veel belangrijker en daar zitten ook de verschillen met VBA.

Dat is er ook meteen de oorzaak van dat C# en VB.NET uiteindelijk niet zo ver van elkaar afliggen.

[JKVA]

Not Pingu schreef op zondag 23 juli 2006 @ 12:58:
[...]


Da's niet waar. VBA en .NET zijn compleet andere ontwikkelplatformen. Je zult weinig van je VBA kennis mee kunnen nemen naar VB.NET, behalve dan dat je het taaltje kent. Kennis van het onderliggende platform is veel belangrijker en daar zitten ook de verschillen met VBA.

Dat is er ook meteen de oorzaak van dat C# en VB.NET uiteindelijk niet zo ver van elkaar afliggen.

Precies, het gaat om het framework dat eronder ligt. Die taal heb je jezelf zo aangeleerd als je bekend bent met OO en zo.

Goed gebruik weten te maken van het framework, weten wat het standaard voor je kan doen, maar ook wat het niet out-of-the-box kan, weten waar en hoe je je performance optimalisaties kunt realiseren en hoe je de security regelt, daar gaat het om, niet de taal.

En als je dan helemaal fanatiek aan de gang wilt, probeer dan meteen NHibernate en NSpring te gebruiken. Ik weet niet hoe de MS kloon is, maar in J2EE werkt het wel goed.

Overigens, sommige van die modules van jullie zijn volgens mij prima met een standaard tool op te lossen, zoals AccountView ofzo. Dat werkt prima voor een administratiemodule. Ook kun je er prima mee communiceren vanuit je applicaties.

Ik zou iig eerst kijken naar hoe je een standaardoplossing in je bedrijfsmodel kunt toepassen, pas daarna overgaan tot maatwerk, dat is in dergelijke gevallen altijd duurder dan een kant-en-klaar koffertje dat je overal eventjes installeert.

[kenneth]

JKVA schreef op zondag 23 juli 2006 @ 14:28:
NSpring

Spring.NET

[/muggenzift]

[JKVA]

kenneth schreef op zondag 23 juli 2006 @ 14:37:
[...]
Spring.NET

[/muggenzift]

You're right. Maarreh, is het iets?

[Sybr_E-N]

MS Access omgevingen kopieren naar een .NET equivalent is een ramp, omdat die twee totaal verschillend zijn. Wil je het goed doen, dan moet je alles opnieuw gaan schrijven (of laten doen door meer ervaren .NETters.)

VB.NET is geen Visual Basic of VBA, meer C# in een ander jasje alleen de meeste syntax lijkt op het oude model. Maar het framework eronder is totaal anders.

Ik heb voor mijn werk dit enkele malen mogen doen, daar waar de klant graag ook het Access idee/look-and-feel in een web applicatie wou houden. Conclusie, drama van de bovenste plank (vooral het laatste gedeelte van de vorige zin).

Ook moet je je access database schema's aanpassen, naar een fatsoenlijk naar 3e normaalvorm ontworpen database-schema. Als je pech hebt moet alles over de kop, maar als de toenmalige DBA-er er wel kaas van heeft gegeten kan het ook zo 123 gepiept zijn. Ook moet je nu een ander type database gaan onderhouden en tunen voor de verschillende applicaties.

Je kunt niet alles in 1 week omzetten, daar gaan maanden zo niet jaren overheen. (ik ga ervan uit dat je alles nog steeds goed wilt hebben voor nu en voor de toekomst.) Daarnaast moeten de programmeur worden omgeschoold, kost ook tijd en geld.

Je kunt het ook stukje bij beetje migreren naar het nieuwe platform en zolang het nog kan op de oude voet verder.

[EfBe]

Tja, de topicstarter heeft een probleem en wil een oplossing, maar de enige oplossing die gaat werken, nl. het kappen met Access en normale software te gaan gebruiken, is geen optie. Dan is er maar een oplossing mogelijk: doormodderen met je huidige spullen.

Access is een single-user applicatie omgeving waarbij je app en db in 1 file kwijt kunt. Het is niet geschikt voor multi-user applicaties en nooit geweest ook. Wil je dat dus wel, dan moet je iets anders kiezen dan Access.

Je Access db's kun je makkelijk migreren naar Sqlserver, bv Sqlserver 2005 Express, wat gratis is en je data makkelijk aankan. Wat rest is het her-schrijven van de clients. Dat is wel wat werk, maar het is niet anders.

[Dido]

EfBe schreef op zondag 23 juli 2006 @ 18:07:
Access is een single-user applicatie omgeving waarbij je app en db in 1 file kwijt kunt. Het is niet geschikt voor multi-user applicaties en nooit geweest ook. Wil je dat dus wel, dan moet je iets anders kiezen dan Access.

Niet om access meteen tot super-oplossing te bombarderen, maar dit is wel heel kort door de bocht.
Niemand verplicht je om in Access alles in 1 file te plempen, je kunt wel degelijk de zooi in een front- en backend opsplistsen, en multi-user gaat prima. Tot een beperkt aantal users.

Je zou in ieder geval de huidige data over kunnen zetten naar MS-SQLserver, of wat dan ook, en je bestaande front-end daar tegenaan laten praten.
Het migreren van je Access VBa frontend is een verhaal apart. Waarschijnlijk is nieuwbouw een snellere oplossing dan migratie.

[f.heinen]

Okay, het omzetten van Access DB naar SQL ben ik mee eens. Maar is hier tijdswinst uit te halen? Maw zal een querie met een SQL DB sneller gaan dan met een Access DB?
Indien dit aantoonbaar is dan kun je de terugverdien tijd snel berekenen (bijvoorbeeld: 40 personen * 500 queries gem/dag * 200 werkdagen/jaar * 1 sec/querie= 138 mandagen per jaar besparing).

Verder wordt er gesproken over .NET of VB.NET. Dit zal dan waarschijnlijk de "beste" oplossing op dit moment zijn maar hoe zit het met compatibility naar de toekomst gezien? Blijven de apps dan werken of moet de hele zaak over 5 jaar weer om? Dit is een belangrijk punt voor het kosten plaatje. Verder is dan waarschijnlijk (een nieuwe versie van) Access overbodig geworden. Dit kan ik dan ook mee nemen in het plaatje.

Is het ook mogelijk om delen van een module/applicatie om te zetten en deze te laten communiceren/koppelen met een Access/VBA module? Dan kunnen we de grote modules/applicaties in delen overzetten.

Wat betreft de code, heb je aan de VBA code nog iets als je met .NET bezig gaat. Dat je delen (vanaf een hardcopy) "overneemt"? Of werkt dit geheel anders en moet je alles echt opnieuw verzinnen?

[JKVA]

f.heinen schreef op maandag 24 juli 2006 @ 00:08:
Okay, het omzetten van Access DB naar SQL ben ik mee eens. Maar is hier tijdswinst uit te halen? Maw zal een querie met een SQL DB sneller gaan dan met een Access DB?
Indien dit aantoonbaar is dan kun je de terugverdien tijd snel berekenen (bijvoorbeeld: 40 personen * 500 queries gem/dag * 200 werkdagen/jaar * 1 sec/querie= 138 mandagen per jaar besparing).

Dat verschil is er zeker. Vooral bij meerdere gebruikers en grote databases wil je niet met Access werken. SQL Server is velen malen beter te tunen.

Verder wordt er gesproken over .NET of VB.NET. Dit zal dan waarschijnlijk de "beste" oplossing op dit moment zijn maar hoe zit het met compatibility naar de toekomst gezien? Blijven de apps dan werken of moet de hele zaak over 5 jaar weer om? Dit is een belangrijk punt voor het kosten plaatje. Verder is dan waarschijnlijk (een nieuwe versie van) Access overbodig geworden. Dit kan ik dan ook mee nemen in het plaatje.

Dit is juist de goede optie m.b.t. de toekomst, maar nu zal het even doorbijten zijn omdat je een nieuw platform moet leren. (of iig de gene die ermee aan de gang gaat ) Overigens, dit is misschien een aardige reden om de klus uit te besteden. Het is namelijk veel werk en bovendien is die externe partij veel beter op de hoogte van de mogelijkheden dan iemand intern op jullie bedrijf. Ook met betrekking tot de onderhoudbaarheid van de applicatie ben je met een specialist vaak beter af.

Jullie interne automatiseerder zal genoeg werk hebben aan het onderhouden van het contact met die partij en het zorgen dat alles soepel verloopt. Ook kan deze zich bemoeien met de niet functionele requirements, zoals performance, security, logging, onderhoudbaarheid, etc...

Is het ook mogelijk om delen van een module/applicatie om te zetten en deze te laten communiceren/koppelen met een Access/VBA module? Dan kunnen we de grote modules/applicaties in delen overzetten.

Lijkt me wel... Hangt een beetje af van hoe de huidige applicatie is opgezet.

Wat betreft de code, heb je aan de VBA code nog iets als je met .NET bezig gaat. Dat je delen (vanaf een hardcopy) "overneemt"? Of werkt dit geheel anders en moet je alles echt opnieuw verzinnen?

Je business logic zou ik bewaren, die zal niet gewijzigd zijn. Hooguit wordt er andere syntaxis gebruikt, i.v.m. de nieuwe programmeertaal, maar de strekking zal gelijk blijven lijkt me.

[EfBe]

Dido schreef op zondag 23 juli 2006 @ 18:16:
[...]
Niet om access meteen tot super-oplossing te bombarderen, maar dit is wel heel kort door de bocht.
Niemand verplicht je om in Access alles in 1 file te plempen, je kunt wel degelijk de zooi in een front- en backend opsplistsen, en multi-user gaat prima. Tot een beperkt aantal users.

Dan gebruik je niet MS Access, maar puur een file. De db activiteit wordt dan nl. door de driver IN de client gedaan. De TS gebruikt (als ik het goed gelezen heb) MS Access als applicatie platform: dus app + db zit in de mdb en wordt IN access gerunned

Je zou in ieder geval de huidige data over kunnen zetten naar MS-SQLserver, of wat dan ook, en je bestaande front-end daar tegenaan laten praten.

Hij heeft geen front-end dat dat kan.

[JJvG]

'k Heb zelf ook jaren ontwikkeld in Access/VBA en daarna overgestapt op .NET Grootste project in Access was multi-user met circa 40 gebruikers met een Access voorkant (GUI+modules) en SQL Server achterkant (via lokale ODBC koppeling).

Je hebt met Access een heel eenvoudig pakket, waarmee je redelijk snel kunt ontwikkelen en productiviteit kunt verhogen. Voor omschakeling naar een andere omgeving en IDE (zoals SQL met .NET), heb je een aantal voordelen en een aantal nadelen:

Voordelen zijn:
- Je hebt een voorbeeld, dus functioneel weet je wat de (nieuwe) applicatie moet kunnen
- Je hebt al iets, dus er is geen mega-projectdruk om iets af te krijgen, wat je de tijd geeft om het goed te doen

Nadelen zijn:
- Een goede ontwikkelaard ontwikkelt het snelst met een taal die hij/zij al kent en een nieuwe taal heeft tijd nodig.
- Rapporten in Access kunnen zeer krachtig zijn, en zijn het lastigst om na te bouwen. VBA Modules zullen (technisch en functioneel) eenvoudiger leesbaar en vervangbaar zijn dan complexe rapporten, met subrapporten, queries en VBA code in-een.

Maak niet de vergissing om het pakket uit te willen breiden met NIEUWE functionaliteit want "we zijn nu toch bezig". Probeer eerst het pakket na te bouwen met de bestaande functionaliteit, om zo de talen en structuur goed te begrijpen. Je vraagt je met bestaande functionaliteit vaak zat af "waarom hebben ze dit nou gedaan?" en nieuwe vragen voor nieuwe functionaliteit, maken de realisatie trager. Daarnaast heb je geen voorbeeld van hoe het zou moeten werken...

Ik raad je aan om eerst 1 project/database uit te kiezen met low impact voor de organisatie en met maximaal 5 gebruikers. Liefst een read-only applicatie. Probeer zoiets te migreren naar SQL Server met Access voorkant (lokale ODBC koppeling) en laat de gebruikers rustig doorwerken met Access voorkant en SQL Server achterkant. Kost je (totaal) maximaal een dag (loskoppelen data en GUI en maken ODBC verbinding). Ga daarna op diezelfde SQL Server NOG een voorkant bouwen in .NET (mijn voorkeur zelf heeft VB.NET) en doe hiermee ervaring op in de nieuwe taal.

[Boss]

Nou, ik heb inmiddels toch een flink aantal klanten op Access draaien met of zonder SQL server erachter. En daar zitten best organisaties achter die vergelijkbaar zijn met die zoals jij hem beschrijft. Ik zie dan ook geen enkel probleem om door te gaan op de weg zoals je nu bent. Het is zeker wel aan te raden om alle back-ends om te zetten naar een SQL server. Als je MS-SQL hebt is dat een hele goede keuze, maar Firebird oid werkt ook goed (uit ervaring).

In ieder geval niet gaan omzetten naar .adp-projecten, mocht je die mogelijkheid overwegen. Die functionaliteit wordt niet echt meer doorontwikkeld door MS en is met SQL-2005 niet meer goed beschikbaar.

Upgrade problemen kan je prima voorkomen in Access. Ik denk dat je nu veel problemen hebt met ontbrekende verwijzingen op verschillende computers, maar als je de boel netjes in elkaar zet is dat geen probleem en kan je iedere database wel op iedere computer gebruiken, ongeacht de versies van Office die erop staan.

Tenzij je een bak geld beschikbaar hebt om alles opnieuw te laten ontwikkelen, maar dan nog... Ik kan eigenlijk geen echte voordelen noemen als je Access als front-end gebruikt, waarom je dan over zou moeten stappen naar een 'echte' omgeving als VB / C# / Delphi of zoiets. Hooguit dat het naar de klant toe wat professioneler overkomt als je een losse applicatie hebt.

[kenneth]

EfBe schreef op maandag 24 juli 2006 @ 08:40:
Hij heeft geen front-end dat dat kan.

Access Data Project -> Access frontend, MSSQL backend.

Blijft behelpen, maar het is misschien een nuttige tussenstap.

[lier]

JJvG schreef op maandag 24 juli 2006 @ 08:56:
Nadelen zijn:
- Rapporten in Access kunnen zeer krachtig zijn, en zijn het lastigst om na te bouwen. VBA Modules zullen (technisch en functioneel) eenvoudiger leesbaar en vervangbaar zijn dan complexe rapporten, met subrapporten, queries en VBA code in-een.

Hiervoor zou je heel mooi Microsoft Reporting Server kunnen gebruiken.

[DexterDee]

Swerfer schreef op zondag 23 juli 2006 @ 11:28:
[...]

Waarom meteen C#? VB is bijna net zo krachtig in .NET, en aangezien er al gewerkt wordt met VBA is de overgang naar VB.NET veel gemakkelijker dan het leren van een andere programmeertaal.

Met VB6 versus VC++ heb je gelijk, maar in .NET liggen de kaarten toch wat anders. Qua performance zijn ze precies gelijk, omdat zowel VB.NET als C#.NET naar dezelfde bytecode worden gecompiled en niet meer direct naar machinetaal. Bovendien is VB.NET "krachtiger" als je daarover mag spreken, omdat er veel meer kant en klare resources en libraries beschikbaar zijn dan in C#.NET. Niet dat dit een probleem is, want als de functionaliteit eenmaal gecompiled is kan het zowel in VB.NET als in C#.NET aangeroepen worden

Voor de TS, om een indruk te krijgen of .NET iets is voor de toekomst van je bedrijf, kun je de personal edition van Visual Studio gratis bij microsoft downloaden. Deze is ietwat beperkt maar is blijvend gratis en mag ook commercieel ingezet worden. Het bevat ruwweg dezelfde stijl visuele database controls die Access ook heeft en er is vrij veel op het net te vinden over Access -> .NET migraties. Desalniettemin zal het geen makkelijke opgave worden, maar qua onderhoudbaarheid, schaalbaarheid en uitbreidbaarheid op de langere termijn is het wel de moeite waard om hierover na te denken.

[Boss]

kenneth schreef op maandag 24 juli 2006 @ 09:40:
[...]
Access Data Project -> Access frontend, MSSQL backend.

Blijft behelpen, maar het is misschien een nuttige tussenstap.

Alleen blijf je dan gebonden aan oude versies van MSSQL, aangezien vanaf SQL-2005 dit niet meer wordt ondersteund. Het werkt wel, maar Microsoft gaat het adp-pad (leuk anagram ) niet verder bewandelen.

[JJvG]

Koppeling met SQL Server is helemaal niet zo moeilijk. Kan best goed met het handje:
- Alle gebruikers uit de (access) database (geen .ldb file meer die 'm locked) en (tijdelijk) hernoemen zodat niemand 'm opstart.
- Kopietje trekken naar aparte netwerkshare, zodat je met de KOPIE aan de slag kan.
- Data importeren in SQL Server (uit Access)
- Alle data-tabellen verwijderen uit KOPIE van de Access database.
- ODBC koppeling maken naar SQL Server (bij voorkeur met Trusted Connection, netwerk autorisatie)
- In Access tabellen koppelen met "Link Tables ..." en ODBC koppeling kiezen
- Testen of alle data zichtbaar is (open een tabel).
- Functionalteit testen (open een scherm/rapport)
- KOPIE terugzetten naast origineel en van beiden een backup maken. Origineel verwijderen en bij eindgebruikers een ODBC koppeling aanmaken. Dit kan overigens ook direct vanuit VBA code (op verzoek verkrijgbaar).

[Croga]

Het is natuurlijk heel mooi om te kijken naar een exacte kopie van de huidige situatie maar dan op een ander platform, maar mischien kun je bij zo'n grote overschakeling net zo goed kijken of er in de markt geen "standaard" oplossingen te vinden zijn die je in onderhoud simpelweg veel minder tijd gaan kosten....

Het ziet er naar uit dat er "ERP" software gebouwd is, en dat soort software is tegenwoordig voor zo'n beetje ieder formaat bedrijf ook als standaard oplossing te vinden. Het enorme voordeel daarvan is dat je geen zelf geprogrammeerde software meer nodig hebt, waardoor niet je hele software platform instort zodra er 1 medewerker het bedrijf verlaat. Zo'n standaard oplossing zal wellicht ook maatwerk nodig hebben om aan de eisen van het bedrijf te voldoen, maar veelal is dat veel doorzichtiger dan volledig custom built spul.

Als je dan toch bij Microsoft wilt blijven, ga dan eens kijken naar Navision of zo (ik heb te weinig kennis van "low end" ERP software om daar een goed advies bij te geven, en ik zou je zonder meer afraden om de software waar ik wel iets van weet (SAP) voor een bedrijf van 50 man in te zetten ).

De enige duidelijke conclusie die iedereen hier trekt is dat het niet eenvoudig op te lossen is. Als het dan toch ingewikkeld wordt en veel tijd en geld gaat kosten, kun je wellicht ook eens buiten het "we bouwen alles zelf" concept gaan kijken. Als je het hebt over toekomstvast is zelf ontwikkelen namelijk geen optie meer.

[Dido]

EfBe schreef op maandag 24 juli 2006 @ 08:40:
Dan gebruik je niet MS Access, maar puur een file. De db activiteit wordt dan nl. door de driver IN de client gedaan. De TS gebruikt (als ik het goed gelezen heb) MS Access als applicatie platform: dus app + db zit in de mdb en wordt IN access gerunned

offtopic:
Je kunt wel degelijk een access front-end en een access-backend gebruiken. Die back-end kun je prima vervangen door om het even wat, als het maar via ADBC benaderd kan worden.
Zolang beiden mdb-bestanden zijn gebruik je echter volledig Access.
Maar goed, ik weet niet hoe zinnig het is om veel dieper in te gaan op de mogelijkheden die linked tables bieden in Access.

Hij heeft geen front-end dat dat kan.

offtopic:
Misschien niet (als ie 1 .mdb heeft), maar dan kost het vijf minuten, en dan heeft ie hem wel.
Zoals hierboven al opgemerkt, geen ideale oplossing, maar misschien een handige tussenstap.

[Verwijderd]

Nou zeg ik natuurlijk iets heel raars: maar heb je aan filemaker 8.5 gedacht?

ik werk zelf bij een bedrijf met filemaker 7.0v3. Ik heb het eigenlijk nog nooit zo simpel gezien als dit, en toch zo uitgebreid. Je kunt de demo downloaden van filemaker.com ,je kan het altijd proberen.
Daarbij gaat 8.5 ook webbased

Ik neem aan dat je eigenlijk alleen het pakket voor BA wilt? FA moet je natuurlijk gewoon een standaard pakket nemen, geen filemaker maar zeker ook geen access, daar kan je niet tegen op bouwen.

[ Voor 74% gewijzigd door Verwijderd op 24-07-2006 11:08 ]

[JKVA]

Croga schreef op maandag 24 juli 2006 @ 10:28:
Als je dan toch bij Microsoft wilt blijven, ga dan eens kijken naar Navision of zo (ik heb te weinig kennis van "low end" ERP software om daar een goed advies bij te geven, en ik zou je zonder meer afraden om de software waar ik wel iets van weet (SAP) voor een bedrijf van 50 man in te zetten ).

SAP heeft MKB oplossingen, zoals mySAP, dus je weet maar nooit of het iets is. Ik ben overigens geen SAP fan. Op mijn werk gaat ook niet alles soepel op de gebieden waar SAP wordt ingezet. (en we hebben toch een stuk of 100 SAP'ers in dienst)

Verder zijn er enorm veel ERP/CRM/etcetera aanbieders te vinden. Kijk voor de grap eens hier:
http://www.crmsystemen.nl/ (kun je ook doorklikken naar ERP en zo)

[f.heinen]

Zoals ik nu alle reacties lees, is er nog maar 1 ding rendabel en dat is de omzetting van een MS Access DB naar een mySQL/MS SQL DB (of een andere variant).

Uit de reacties om het om te zetten naar C#.NET of VB.NET kan ik zeker nog niet uithalen dat ik daarmee (ongeveer) 2,5 man jaar uit ga halen om alles om te zetten naar een andere taal.

Wat betreft de reacties die het hebben over een ERP systeem. Deze modules hebben niet direct met ERP te maken. Een deel is automatiseringsschil om ERP heen. En een ander (voor zover dit gescheiden gezien kan worden) is een engineeringsschil om de projecten in uit te werken. We hebben zelfs onlangs weer een nieuw ERP systeem aangeschaft (met een SQL DB) om zo beter te kunnen koppelen.

Wel zie ik een verschil (voor zover ik onze modules begrijp en ik de uitleg van een jullie begrijp)
in de database interactie. In ons geval worden veel van de DB's naar de lokale machine gekopieerd om zo de snelheid te garanderen en ook te garanderen dat niet meerdere users dezelde records overschrijven. Ik denk dat dit met SQL niet meer realiseerbaar is en weet ook niet waarvoor dit handig is/was en waarom dit gedaan is. Ik weet wel dat het nu in alle modules verwerkt zit dus dat het omzetten naar SQL nog niet een klus is van 1 uurtje....

[JKVA]

f.heinen schreef op maandag 24 juli 2006 @ 20:10:
Wel zie ik een verschil (voor zover ik onze modules begrijp en ik de uitleg van een jullie begrijp)
in de database interactie. In ons geval worden veel van de DB's naar de lokale machine gekopieerd om zo de snelheid te garanderen en ook te garanderen dat niet meerdere users dezelde records overschrijven. Ik denk dat dit met SQL niet meer realiseerbaar is en weet ook niet waarvoor dit handig is/was en waarom dit gedaan is. Ik weet wel dat het nu in alle modules verwerkt zit dus dat het omzetten naar SQL nog niet een klus is van 1 uurtje....

Hoe los je dit probleem nu dan op? Het kopieren naar lokaal lost in feite namelijk niets op, aangezien je op den duur weer moet synchroniseren zodat iedereen weer met dezelfde gegevens werkt. Zoiets is met een gecentraliseerd systeem gemakkelijker te regelen, aangezien goede DBMS'en zoals MSSQL functionaliteiten bieden m.b.t. concurrency en locking en zo.

Overigens zijn er al veel ideeen geweest over het kijken naar een pakket in plaats van dit maatwerk. In hoeverre heb je daar al naar gekeken?

[curry684]

f.heinen schreef op maandag 24 juli 2006 @ 20:10:
In ons geval worden veel van de DB's naar de lokale machine gekopieerd om zo de snelheid te garanderen en ook te garanderen dat niet meerdere users dezelde records overschrijven.

Uhhhhh dus om concurrency te voorkomen schaf je concurrency maar af en zorg je ervoor dat iedereen afzonderlijk van elkaar dezelfde records tegelijk mag overschrijven zodat je vervolgens de helft kwijtraakt als je het terugmerget in een master copy? Of mis ik nu iets?

Het hele idee van een client/server database als MS SQL is juist dat je al die copy overhead niet hebt en er granular locking kan plaatsvinden om daarmee latencies zo ver mogelijk te verminderen. In plaats van 50 sterke clients met stevige netwerkpijpen heb je dan genoeg aan 50 minimale clients en 1 stevige DB-server.

50 is in het algemeen ver over de praktische grens waar Access nog performant uit de hoek komt als je echt concurrent werkt, maar ik snap echt geen bal van wat je nu doet met die local copies: dat klinkt echt als een HAVO-hobby-developer oplossing die meer problemen veroorzaakt dan oplost.

[EfBe]

f.heinen schreef op maandag 24 juli 2006 @ 20:10:
Zoals ik nu alle reacties lees, is er nog maar 1 ding rendabel en dat is de omzetting van een MS Access DB naar een mySQL/MS SQL DB (of een andere variant).

Problemen moet je oplossen met een oplossing die duurzaam of je krijgt onherroepelijk het probleem later weer terug. Dus nu een prutsoplossing verzinnen die je even door de moeilijke periode helpt lijkt leuk, maar kan nare gevolgen hebben: nl. dat je gewoon tijdverliest en hetzelfde probleem volgend jaar weer hebt.

Automatisering en software engineering is niet iets wat je 'even' op de zondagmiddag doet, je moet goed nadenken over wat je doet en waar je mee bezig bent. Een 'handige jongen' met access kan wellicht heel wat maken, maar of dat ook lang stand houdt is maar de vraag.

Wat betreft de reacties die het hebben over een ERP systeem. Deze modules hebben niet direct met ERP te maken. Een deel is automatiseringsschil om ERP heen. En een ander (voor zover dit gescheiden gezien kan worden) is een engineeringsschil om de projecten in uit te werken. We hebben zelfs onlangs weer een nieuw ERP systeem aangeschaft (met een SQL DB) om zo beter te kunnen koppelen.

Waarom wordt er zoveel geld gestoken in ERP maar blijven jullie rommelen met Access? Onbegrijpelijk.

Wel zie ik een verschil (voor zover ik onze modules begrijp en ik de uitleg van een jullie begrijp)
in de database interactie. In ons geval worden veel van de DB's naar de lokale machine gekopieerd om zo de snelheid te garanderen en ook te garanderen dat niet meerdere users dezelde records overschrijven. Ik denk dat dit met SQL niet meer realiseerbaar is en weet ook niet waarvoor dit handig is/was en waarom dit gedaan is. Ik weet wel dat het nu in alle modules verwerkt zit dus dat het omzetten naar SQL nog niet een klus is van 1 uurtje....

Waar je denk ik niet aan ontkomt is opnieuw je probleem bekijken, analyse doen en dan nieuwbouw. Dat hoeft niet veel te kosten, wellicht kun je veel dingen delen en zijn de taken die veel mensen doen met de software niets anders dan het gebruiken van CRUD schermpjes.

Maar het moet wel GOED. Prutsware heeft niemand wat aan.

[f.heinen]

Dit is zeker maatwerk is absoluut zeker niet op de markt te verkrijgen (misschien een paar kleine mogelijkheden wel). Functioneel werkt het verder goed.

Er kan wel gezegd worden dat dit rommelen met Access is en dit een hobby oplossing is maar er werkt wel een Universitair opgeleid persoon aan! Ik wil niet zeggen dat de keuze die 5 jaar geleden gemaakt is (toen het nog een stuk minder met het bedrijf ging en er niet veel grote automatiserings plannen waren) de goede keuze is gemaakt. Ik betwijfel het. Aan de andere kan, net een jaar ervoor is ATAG in Arnhem failliet gegaan aan de implemenatie van een mooi bedrijfsspecifiek ERP systeem. Dit was toen ook een van de voorvallen die wel vertelde dat je ook te ver kon gaan met de eerste stappen van automatisering.

Verder heeft de automatiseerder wie toen aangenomen is (voor zover ik weet) niets te zeggen gehad over het te gebruiken platform. Verder waren de plannen zoals ik al aangaf klein (aanstelling voor de automatiseerder max 6 maand en nu werkt hij er al 5 jaar en zal ook vast blijven).

Zonder te ver in detail te treden, wij ontwerpen zeer specifieke producten die op maat worden ontworpen. Dit systeem zorgt voor allerlei documenten en berekeningen voor deze producten met minimale input.

Over het locale DB verhaal weet ik geen details over te vertellen. Of dit nu aan een MS Access bug lag in de Office 2000 relais (eerste release) en dit verder is doorgevoerd. Of dat er andere dingen aan te grondslag liggen. Ik heb geen idee. Er is wel degelijk over na gedacht.

Het verdere probleem van 1 programmeur is dat het niet te controleren is of hij de opzet van het systeem goed doet. Ik heb geen/weinig verstand van VBA dus kan er niets over zeggen terwijl ik er feitelijk een van de weinige mensen ben die het een beetje kan lezen en verklaren.... Functioneel leverd hij zeker goed werk.

Ik denk dat de overstap naar SQL een kwestie van tijd is en daarbij het lokale DB verhaal ook achterhaald zal zijn.

Verder is het wat ik al zeg op dit moment een puur kosten baten verhouding. Het omzetten van 5 jaar werk zal zeker een hoop tijd gaan kosten. Ik denk dat dit in combinatie met het niet meer door ontwikkelen van de automatisering in deze tijd (onze modules worden continue verfijnt en verbetert) zeker geen haalbare kaart is (als je alles in 1 keer over wilt zetten).

Het zal dan gaan om over te stappen naar een ander platform en stapsgewijs modules om te zetten en nieuw te ontwikkelen. En dit zou ik graag willen (laten) vergelijken. Echter gezien jullie reacties betwijfel ik er een reële kosten baten berekening gemaakt kan worden.... De problemen van nu kunnen we duidelijk in kaart brengen maar de voordelen/nadelen van het overstappen is zonder harde cijfers van preformance voordeel, programmeertijd winst en werksnelheid, slecht weer te geven. Hierdoor zal de directie natuurlijk nooit voor deze investering kiezen of er moet duidelijk aangegeven kunnen worden dat de huidige weg die we bewandelen een doodlopende weg is.....

De "problemen" die we nu hebben zijn niet onoverkomenlijk alleen moeten we er wel voor zorgen dat ze dan niet worden. Omdat het overzetten naar de nieuwe Access/VBA problemen veroorzaakt en we op dit moment een aantal problemen hebben vroeg ik me dus af of de weg die we nu bewandelen de juiste is.

Uit de reacties lees ik uit dat er een aantal problemen opgelost kunnen worden door over te gaan naar SQL icm een grote DB server en het opdoeken van de locale DB's. Hierdoor zal er een hoop tijdswinst kunnen behaald worden. Ik vraag me dus af of het na het overzetten naar SQL haalbaar is om verder te gaan met een ander platform als .NET oid. Gezien de kosten (opleiding, software, overzetten van modules) vraag ik me dat af.

[Sybr_E-N]

Stilstand is achter uitgang. VBA in op zijn retour, je kunt er gerust jaren mee blijven werken natuurlijk. Maar de nieuwe Office versie's werken gewoon met .NET (VSTO).

Waarom vraag je dit soort adviezen op een forum? Dat lijkt me nou niet de beste plaats om dit te verkrijgen, ookal zijn er een aantal GoTters die er enige kaas van hebben gegeten natuurlijk. Ga eens lang bij enkele automatiseerders (heb je ook in alle soorten en maten). Ik denk dat die je veel verder kunnen helpen bij het opzetten met dit hele process, wat op de schop moet.

[JKVA]

Sybr_E-N schreef op dinsdag 25 juli 2006 @ 21:12:
Waarom vraag je dit soort adviezen op een forum? Dat lijkt me nou niet de beste plaats om dit te verkrijgen, ookal zijn er een aantal GoTters die er enige kaas van hebben gegeten natuurlijk. Ga eens lang bij enkele automatiseerders (heb je ook in alle soorten en maten). Ik denk dat die je veel verder kunnen helpen bij het opzetten met dit hele process, wat op de schop moet.

Probeer idd eens je primaire IT behoeften eens bij elkaar te zetten, te kijken hoe het nu werkt, hoe dat gaat en hoe je het zou willen hebben.

Werk dat eens uit tot een concreet document. Soort Vision, zoals uit RUP.
http://en.wikipedia.org/wiki/Rational_Unified_Process

Zie deze site voor een template:
http://www.rupopmaat.nl/downloads.html

Zet daarin wat je visie is, ga daar nog eens flink met de rode pen doorheen en zorg dat je niet teveel wilt. Vaak kom je bij het schrijven van een dergelijk document weer tot ideeen. Laat het ook aan anderen lezen. Ook mensen die met het systeem moeten gaan werken. (juist die mensen, die weten vaak het beste wat de problemen zijn)

Klaar? Leg dat dan eens bij de directie neer. Al is het maar even om te polsen hoe gevoelig het ligt.

Als ze daar positief zijn, kun je eens gaan kijken bij externe partijen om daar eens een gesprek mee te hebben. Zelfs in dit stadium kunnen die wel zeggen of iets haalbare kaart is gezien de tijds- en financiele beperkingen. Waarschijnlijk komen zij zelfs met ideeen en zaken die je misschien van je wensenlijst moet halen.

Zo kun je stapje bij beetje wat inventariseren en polsen. Dat geeft je iets meer duidelijkheid en bovendien houvast om mee te communiceren naar derden.

Vaak werkt gewoon beginnen beter dan eindeloos denken.

[f.heinen]

Tuurlijk ga ik niet direct af op adviezen op het forum maar het is wel een goede maatstaf als er veel mensen zeggen dat hetgeen we nu doen/gebruiken niet de juiste is. Verder verwacht/hoop ik hier een richting te krijgen waar ik een oplossing kan vinden.....

Nu heb ik die door jullie adviezen gevonden: een richting, mogelijke oplossingen, mogelijke verbeteringen...

Dit is hetgeen waar ik naar opzoek was. Met andere woorden: heel hartelijk bedankt voor jullie hulp en adviezen!!! Ik ga de ideeën eens bespreken met de automatiseerder om hier een toekomst visie uit te generenen. Indien hieruit komt dat het ons een optie lijkt om over te stappen dan gaan we hier een voorstel voor maken aan de directie.

[curry684]

f.heinen schreef op dinsdag 25 juli 2006 @ 21:02:
Er kan wel gezegd worden dat dit rommelen met Access is en dit een hobby oplossing is maar er werkt wel een Universitair opgeleid persoon aan!

Nounou, I'm impressed

Ik heb WO'ers meegemaakt in ICT-richting die nauwelijks een for-loop konden schrijven, en merendeel kan geen query optimaliseren, laat staan de voordelen van SQL Server boven Access fatsoenlijk uitleggen of een gedegen advies over systeemarchitectuur geven.

[JKVA]

Nog een hint. Pin je nog niet vast op tools zoals er onder andere hier zijn aangegeven, zoals MSSQL, Access, C# of VB(.NET).

Bepaal eerst eens wat je wilt en ga daarna eens kijken wie je daar het best bij kan helpen. Misschien kan een (kleine) automatiseerder die met bijvoorbeeld PHP en MySQL werkt, het ook prima voor elkaar krijgen voor een fractie van de prijs. Om van licenties nog niet te spreken. Of natuurlijk een prachtige J2EE 8 lagen oplossing.
Zelfde geldt voor de database. MSSQL is nieuw voor jullie, maar Oracle evenveel, dus misschien is die overstap wel slim. Aan de andere kant kun je met een open source oplossing zoals een PostGreSQL database waarschijnlijk ook vooruit. Zolang er maar een goede import/export functionaliteit is voor jullie oude systeem kan elke DBMS ermee door.

Het feit dat er geen Linux kennis aanwezig is, zou ik voorlopig niet te hard laten meewegen. "Echte" kennis van Windows servers is er misschien ook niet. Goed serverbeheer is iets anders dan XP Home opstarten en MSN installeren. Niet om iets te suggereren of flamen richting jullie, meer een algemene opmerking.

[Croga]

f.heinen schreef op dinsdag 25 juli 2006 @ 21:02:
Zonder te ver in detail te treden, wij ontwerpen zeer specifieke producten die op maat worden ontworpen. Dit systeem zorgt voor allerlei documenten en berekeningen voor deze producten met minimale input.

Documenten en berekeningen sla je, neem ik aan, niet in Access op. Dat betekend dus dat Access een hele andere functie heeft in het hele verhaal. Die functie zal nagenoeg zeker door een standaard product opgevangen kunnen worden zodat je niet alles opnieuw zelf hoeft te gaan bouwen. Als je vervolgens een standaard product kiest wat makkelijk aan te passen is kun je die documenten en berekeningen vervolgens weer daar aan toe voegen.

[Stefke]

Wat ouder, maar voor mij momenteel zeer actueel.

JJvG schreef op maandag 24 juli 2006 @ 10:22:
Koppeling met SQL Server is helemaal niet zo moeilijk. Kan best goed met het handje:
- Alle gebruikers uit de (access) database (geen .ldb file meer die 'm locked) en (tijdelijk) hernoemen zodat niemand 'm opstart.
- Kopietje trekken naar aparte netwerkshare, zodat je met de KOPIE aan de slag kan.
- Data importeren in SQL Server (uit Access)
- Alle data-tabellen verwijderen uit KOPIE van de Access database.
- ODBC koppeling maken naar SQL Server (bij voorkeur met Trusted Connection, netwerk autorisatie)
- In Access tabellen koppelen met "Link Tables ..." en ODBC koppeling kiezen
- Testen of alle data zichtbaar is (open een tabel).
- Functionalteit testen (open een scherm/rapport)
- KOPIE terugzetten naast origineel en van beiden een backup maken. Origineel verwijderen en bij eindgebruikers een ODBC koppeling aanmaken. Dit kan overigens ook direct vanuit VBA code (op verzoek verkrijgbaar).

Ik heb ook een aantal programma's lopen bij klanten, access-fe met access-be, tot nu toe met tot 20-25 gelijktijdige (niet noodzakelijk concurrent!) gebruikers, waarbij de hoeveelheid data oploopt tot tabellen met 20.000 en zelfs 200.000+ records
Vanwege lichte performanceproblemen (met name als in dat bedrijf op wat langzamere computers gewerkt wordt) heeft één van mijn klanten gevraagd of ik iets kan bieden op basis van een andere database (en mogelijk zelfs webbased clients). Mijn advies was om bij eventuele overgang inderdaad eerst de database over te zetten naar bijv. SQL en pas daarna te gaan kijken naar eventuele andere clientmogelijkheden (bijv. webbased schermen voor alleen inkijkwerkplekken)

Daar ben ik sinds een paar dagen een beetje naar aan het kijken
- Visual Web developer gedownload (maar nog niks mee gedaan)
- MS SQL Server express 2005 geinstalleerd
- database overgeheveld naar SQL en de tabellen gekoppeld via OBDC

Op zich probleemloos, maar na het maken van een paar testqueries (daarbij één van de meest ingewikkelde queries uit de client omgezet naar tabellen uit de SQL-server) ben ik niet echt overtuigd van de snelheid
De query opent zich vanuti Access in ongeveer 4 seconden, vanuit SQL duurt dat wel een seconde of 10. En dan staat de SQL-server lokaal op mijn desktopcomputer (Athon XP2600) terwijl de accessdatabase op een share op mijn slome PII-servertje staat!!
Als ik de SQL-server op mijn PII-servertje gebruik loopt deze tijd op tot > 30 sec. (maar goed, aangezien MS al een PIII600 minimaal adviseert voor SQL-2005 snap ik dat dat niet reeel is... )
Maar met deze resultaten hoef ik niet over.

Nu weet ik van Access dat deze ongeveer alle data binnenhaalt en dan door de client alle querys laat doen (o.a. netwerkbelasting), en dat dat bij SQL in principe allemaal aan de serverkant kan gebeuren.

Mijn vraag is alleen; ik heb redelijk ingewikkelde queries op queries gemaakt, met daarin ook nog parameters gevoed vanuit de client.
Is het mogelijk om op de SQL-server queries te maken die door parameters uit de (Access)client al beperkt worden in het aantal records dat weergegeven wordt?


Ik had eigenlijk gehoopt dat SQL-server in ieder geval een winst op snelheid zou geven (ook bij het oplopen van het aantal records, want uit de grootste tabel zijn onlangs een 150.000 records verwijderd om performance iets te verbeteren!) maar het lijkt erop dat dat nog niet zo maar gaat lukken helaas.

(het gaat mij vnl. om performance, ik weet dat SQL-server betrouwbaarder is en zo, dat is alleen maar mooi meegenomen dan)

[ Voor 7% gewijzigd door Stefke op 17-10-2006 21:59 ]

[NetForce1]

Een paar honderdduizend records is een peuleschil voor SQL Server, daar zal het niet aan liggen. Ik denk dat een paar goede indexen al een grote winst opleveren. Daarbij is het wellicht ook handig om eens een kritische blik op je queries te werpen, als ik het zo eens lees is daar ook nog wel wat te optimaliseren lijkt me.

[JJvG]

stefijn schreef op dinsdag 17 oktober 2006 @ 21:38:
...heel verhaal...

Op zich probleemloos, maar na het maken van een paar testqueries (daarbij één van de meest ingewikkelde queries uit de client omgezet naar tabellen uit de SQL-server) ben ik niet echt overtuigd van de snelheid
De query opent zich vanuti Access in ongeveer 4 seconden, vanuit SQL duurt dat wel een seconde of 10. En dan staat de SQL-server lokaal op mijn desktopcomputer (Athon XP2600) terwijl de accessdatabase op een share op mijn slome PII-servertje staat!!
Als ik de SQL-server op mijn PII-servertje gebruik loopt deze tijd op tot > 30 sec. (maar goed, aangezien MS al een PIII600 minimaal adviseert voor SQL-2005 snap ik dat dat niet reeel is... )
Maar met deze resultaten hoef ik niet over.

Alternatief testscenario waar ik wel nieuwschierig naar ben: Maak eens een ODBC koppeling met de Access backend. Dus niet direct gekoppelde tabellen via de Jet4.0 engine, maar dezelfde tabellen door ODBC heen halen. Als je performance dan ook achteruit loopt, weet je dat het aan je ODBC (overhead) ligt.
Edit: Nog een idee: Welke versie van MDAC staat er op de clients geinstalleerd. Volgens mij heeft 2.5 nog last van memory-leaks en 2.6 of 2.8 niet meer. Misschien ook niet, maar ik meen dat dit verschil kan maken. Kun je in ieder geval nog even op zoeken wat de verschillen zijn.

Nu weet ik van Access dat deze ongeveer alle data binnenhaalt en dan door de client alle querys laat doen (o.a. netwerkbelasting), en dat dat bij SQL in principe allemaal aan de serverkant kan gebeuren.

Helaas, guess again: Access haalt eerst al je tabellen (over ODBC) over je netwerk naar je lokale werkgeheugen en gaat dan joinen. Zeker met weinig geheugen of slechte joins kan dit killing zijn voor je performance

Mijn vraag is alleen; ik heb redelijk ingewikkelde queries op queries gemaakt, met daarin ook nog parameters gevoed vanuit de client.
Is het mogelijk om op de SQL-server queries te maken die door parameters uit de (Access)client al beperkt worden in het aantal records dat weergegeven wordt?

Ja. Een mogelijke oplossing is om via Stored Procedures en VBA code je datasets uit te lezen en je mutatie direct op de database te doen (via INSERT of UPDATE statements).

Ik had eigenlijk gehoopt dat SQL-server in ieder geval een winst op snelheid zou geven (ook bij het oplopen van het aantal records, want uit de grootste tabel zijn onlangs een 150.000 records verwijderd om performance iets te verbeteren!) maar het lijkt erop dat dat nog niet zo maar gaat lukken helaas.

(het gaat mij vnl. om performance, ik weet dat SQL-server betrouwbaarder is en zo, dat is alleen maar mooi meegenomen dan)

Zou zeker snelheid op moeten kunnen leveren, maar zoals al gezegd: Kijk ook naar je indexen, kijk naar je queries. Zit het where-statement op de goede plek, zijner inner joins of outer joins gebruikt etc. etc.

Hoor graag je testresultaten

[ Voor 4% gewijzigd door JJvG op 18-10-2006 09:48 . Reden: MDAC versie-idee toegevoegd ]