Myter & fordomme om Access

Jeg har aldrig set noget på skrift.

Men fordomme og uvidenhed er der vid udstrækning. Mest uvidenhed -Et eksempel herpå er fra min arbejdsplads. Der downloader man et regneark med omkring 800 rækker og 6 kolonner. Disse records skal opdateres og lægges på virksomhedens hjemmeside. Det tager ca en formiddag for een enkelt medarbejder manuelt at udføre denne opgave incl alle fejlene. Jeg har dokumenteret, at access kan importere regnearket, vaske data og sende dem tilbage til Excel på ca 5 min. Og så er der ingen fejl. Men det vil man ikke, for jeg skal pensioneres om ca 9 mdr, og hvad skal man så gøre????? Der er 3 ting at gøre:

1. Uddannelse
2. Uddannelse
3. Uddannelse

Een af årsagerne er nok, at i Excel kan man se pæne kolonner og rækker, hvorimod Access nok er lidt mere "abstrakt" at have med at gøre. Men bevares, det er jo et spørgsmål om at vise data i f.eks. en fortløbende formular og formattere denne, så det ser pænt ud.

Og jeg kan blive ved - Men må nok erkende, at min arbejdsplads lider af akut "Access-forskrækkelse".

Hej Mogens

Tak for dit input ... og held og lykke med dit otium ... mangler selv fortsat ca. 15 år endnu :-(

Reelt er det også mest regneark vi benytter som dataprovider/rapportmedie, så det er ikke det der er årsagen ...

Mine 2 cents:

Fordele: Det er nemt hurtigt at lave noget relativt kompliceret. Derfor ligger der som regel en masse access databaser rundt omkring i store firmaer. På et eller andet tidspunkt kan nogen af disse applikationer blive mere populære og mere brugte. Det er der ikke noget galt i, men på det tidspunkt skal access databasen laves om. Her kan der bliver problemer med at give alle adgang til det rigtige netværks drev. Problemer med rettigheds styring på forskellige records, der kan væer performance problemer når mange henter store mængder data fra en fil på netværks drevet.

Man kan så opgradere på flere måder. Man kan lave backenden til acces om, så dataene ligger i en SQL database istedet. Man kan også opdatere både frontend og backend. Det gode ved at opgradere acces her, er at man så har en rigtig god kravspecifikation til et produkt som man ved vil blive brugt meget.

Et problem med acces kan være, at folk begynder at maile den rundt til hinanden.

Nå, lidt om mine oplevelser med acces, håber du kan bruge det til noget.

http://www.blueclaw-db.com/microsoft_access.htm

Mine erfaringer med access.

Det virker fint, når der er få samtidige brugeren, men databasen låser og korrupteres når flere brugere og mere data kommer til.

Desuden har access den tilgang til input, at den vil gøre alt for at indsætte din data - dette er ikke en god ting.
Tag f.eks. datoen 13-12-2009 (13 december 2009). Access vil indsætte den korrekt.
Datoen 11-12-2009 vil derimod blive indsat som 12 november 2009, fordi den standard benytter amerikansk input mask (mm-dd-yyyy). Men når måneden lige pludselig bliver over 12 (som ved 13-12-2009), vil den please brugeren og indsætte som europæisk format. Det er ikke god stil at acceptere alt og indsætte det efter forskellige regler. Der er garanteret nogle settings, hvor man ændrer input mask og giver fejl ved forkert input - men det er unødigt besvær at skulle sætte sig ind i - specielt hvis der benyttes flere databaser, der skal konfigureres ens.

Et andet eksempel er + operatoren, der har 2 funktioner alt efter om operanderne er tal eller tekst:
2 + 2 = 4
"2" + "2" = "22"
Det giver ikke mening, når der til tekst er & operatoren, der udfører tekst concatenation:
"2" & "2" = "22"

Jeg vil foreslå, at du følger din IT direktørs anvisning og finder en anden løsning (evt. MySQL) eller beder ham om en anden teknologi at benytte.

/1

>kvadratrodenaf1

Jeg er enig i dine synspunkter al den tid at databasen ikke er udviklet med omtanke og de rette kompetencer, men dette er vel gældende for enhver form for applikationsudvikling ... så er det vel ikke metoden og værktøjet der er problemet, men processen og manglende kvalitetssikring af data.

Jeg mener selv, og andre herinde vil sikkert tilkendegive at de har de fornødne kompetencer som sikrer at alle disse uhensigtsmæssigheder er opsnappet af en error handler !!!

Microsoft continue releasing newer version of Access with more and more smart feature. There must obvioulsy be a need for these otherwise I'm sure MS would stop doing so.
There are those who think that Access is just for amatures and small companies but from my experience I can assure them that some of DK's larges companies also use Access.

Its just a case of using the right tool for the right task.

There are good and bad things with Access but then there is with ALL other development tools.

If a companies applications are made in Access and work satisfactory then I dont see the point in remaking them in for example .NET, but it may be justifiable to make new applications in .NET.

If your company have decided to drop Access and go over to some other system then lets hope that they are prepared to accept the costs involved too.

Langt hen ad vejen handler performance om at lave det rette design.. Men Access _er_ mere ustabil end f.eks. MySQL.

Jeg startede for 5-6 år siden med en access database, som i starten performede fint. Med tiden bleve den ustabil fordi flere brugere kom til, og jeg besluttede at konvertere til MySQL. Applikationen blev hurtigere og mere stabil. Og med MySQL er data ikke lige pludseligt blevet korrupt eller låst, som det skete med Access mindst en gang om måneden. Sidenhen er databasens struktur vokset 2-3 gange større med mange flere records og traffik. Og den performer stadig godt.

Jeg benyttede dette værktøj til at konvertere: http://www.bullzip.com/products/a2m/info.php

Med en direkte konvertering kørte alting pludselig perfekt.

/1

MySQL???

Can you make your user inteface in MySQL?

If I wanted to continue using Access as th frontend then Id use MSSQL Express

Jeg er også helt med på, at man kan få mere ud af at benytte en SQL-serverløsning ...

Reelt er udfordringen, at jeg (endelig) har fået overbevist virksomheden om at det eneste rigtige en Business Warehouse løsning .... på en SQL-server ... med eet eller andet BI værktøj ovenpå

Min pointe er, at den forretningslogik jeg hidtil har benytte mig af til at generere løsninger med, altså enkeltstående Access løsninger med distribution af diverse rapportpakker herfra, skal løftes til en mere fremtidssikret, performancemæssig og stabil løsning ... men jeg vil da fastholde at de forretningslogik der nødvendigvis skal til, fortsat kan genereres ved hjælp af Access

Nu er det ikke beskrevet, at Access benyttes som front-end til applikationen. Men man kan jo altid lave en ODBC connection til en MySQL database, hvis det skulle være.

Og hvis der som beskrevet ikke er ønske om at benytte Access, må dette vel nødvendigvis også omhandle forms i Access.

Access benyttes princippielt 'kun' som frontend til at opstarte en data-forædling af data, dvs. konvertering af data til
information i forhold til den gældende forretningslogik.

Herudover benyttes Access udelukkende til efterfølgende dataudvælgelse/filtrering til de underlæggende rapportpakker som i den sidste ende ender som pivotrapporter i Excel

You could do all of that in MSQL Server no problem and export to Excel

Hi Terry

I still assume that the lack of knowledge as to how Access actually works ... and as MUGS mentioned

The IT guy's lack of education :-)

Yes the IT guy's lack of education :-)

Hvis det er lavet ordentligt kører access godt, også med masser af brugere/dataindtastninger og diverse rævestreger.

Den helt store force er.....

Hastighed med nyudvikling af moduler/rapporter osv.. lige meget hvilket system i vælger til jeres virksomhed (med mindre i opbygger det hele selv) så vil der være redskaber der mangler, rapporter der ikke er som i vil have dem, grafer, grafer, grafer osv. Her er valget at leve med manglerne eller lappe hullerne.

Access kan det sidste, hurtigt og effektivt...

Min erfaring er, at der altid vil ende med en eller anden form for ERP-/produktionssystem, som kører det værdiskabende og som skriver direkte i regnskabet.. derudover vil der for at optimere og for at klare hverdagen blive lavet diverse sub systemer i excel og access..

Spørgsmålet er bare hvor stor en del man som access udvikler kan få lov at sætte sig på....

Jeg har selv kæmpet mange krige og måtte tage mange slag, men de kan ikke slå access ihjel!~)

...et godt råd... få så meget som muligt ned i en SQL server (eller MySQL!~) for så kan access altid rykke rundt med data...

Det er glædeligt at der er andre der af og til oplever at man er en en-mands hær på dette område, uanset hvor gode argumenter og/eller metoder :-)

Problemet med access er at det ikke er en databaseserver og tabellerne vokser. Med Access skal hver brugere "downloade" hele tabellen hver gang der skal lave en forspørgelse og det belaster netværket betydeligt.

En SQL server er vejen frem, da den kun skal leverer resultatet af en SQL forspørgelse og ikke hele tabellen eller *.mdf filen til den enkelte computer.

Som en anden skrev, kan Access stadig bruges som klient med ODBC.

Det er ikke så svært, men måske skal der lige ryddes lidt op i SQL.

Jeg har lidt mere tillid til din nye IT chef og ja, det sucks at få en ny chef som skal lave alting om og give mere arbejde, men han har ret.

Men der er jo tit mange små projekter, hvor man ikke har tid/råd til at lave det hele med f.eks. winforms og MS sql server.

Når en af de små projekter så går hen og bliver stor er der flere måde at upsize acces på. Man kan blandt splitte den op i en frontend og backend fil. Så bliver det hele ikke hentet ned hver gang. Man kan også vælge at flytte backenden op på en SQL server, så bliver alle data heller ikke hentet ned hver gang. Acces er et fint valg som frontend til forskellige små sql server databaser.

Det der er spændene er jo at høre hvad IT cheffen vil have ind i stedet for, for hvis man bare fjerner access, bliver det svære at starte små dynamiske initiativer op.

Jeg har tidligere arbejdet i en konsulent virksomhed, hvor vi tit kom ind i en virksomhed, som havde flere dynamiske små projekter i acces. Nogen af de projekter var så blvet meget store, med mange brugere, på forskellige sikkerheds nivauer, hvorefter projektet skulle udvides. Det var så vores job at lave et nyt system, hvor sikkerhedsmodelelr og sådanne ting blev tænkt ind i det.

Der var dog stadig mange projekter i virksomhden som kørte i access, hvor der kun var et lille antal brugere involveret, og her var det ikke nødvendig at få det hele skaleret op til et stort dyrt smart produkt fra en konsulent virksomhed.

>jape44

Var jeg blevet stillet over for et oplagt alternativ, ville jeg også gerne acceptere dette, men når hovedkonklussionen som udgangspunkt er at der skal laves en SQL-serverløsning hvorpå der skal genereres nogle forædlede data ( i første omgang 1-1 konvertering af eksisterende Access logik ), må det da være at foretrække at man genbruger såvel eksisterende kompetencer som eksisterende modulkoder )

Det er vel det mest logiske ... der er jo ikke noget i vejen med metoden og i mine øjne

jensen363: der er jeg meget enig, men genbrug access som klienter og smid data over på en server.

2c har en meget god pointe i sit indlæg.

Hello again

Nu er vi nået til den erkendelse, at vi skal have etableret en SQL-serverløsning ... med Access som front end :-)

Er der nogen som kan være behjælpelig med en minimum kravsspecifikation for såvel hard- som software.

Brug det i har :-)

Ny drejning på problemstillingen !!!

Hvis vi istedet skal benytte en Oracle-serveløsning i stedet for SQL-server

Hvad er mulighederne/begrænsningerne hvis vi fortsat vel benytte Access som klient/frontend.

hadnt seen the last comment there.

There are ODBC drivers for Oracle too so you can link your oracle tables to access as you do with SQL Server