23. januar 2003 - 14:11Der er
11 kommentarer og 3 løsninger
2000 Access database går ned 3 gange pr. måned.
Jeg har en Access 2000 database kørende. Denne database går ned 2-3 gange pr. måned, og databasen skal tit komprimeres. Problemet løses PT. ved at reparere og komprimere databasen. Der er 100 brugere tilsluttet systemet via workgrp. Systemet er opdelt med en datafil på server og program filer hos den enkelte bruger. Er der nogle årsager til disse nedbrud, og er det rigtigt at en opbygning på en SQL server kunne være løsningen ?
Hvis SQL er løsningen hvor mange data kan denne så rumme før man skal komprimere ?
Er det rigtigt at SQL database er langsommere end en almindelig database ?
access er overhovedet ikke bygget til at være på nettet - så hvis der ligger mange data i og hvis den bliver brugt meget så er det grunden til at den går så meget ned
SQL server, MySQL eller Oracle derimod er i modsætning til access gearet til at fungerer på nettet, så hvis du skifter vil du med en af disse alt andet lige få en mere stabil og faktisk også en hurtigere database.
Så umiddelbart lyder det som enem eget god idé at skifte til en anden database - det der så skal overvejes er prisen; oracle og sql server koster kassen hvorimod mysql er gratis...
Hvis bare mere end 10 brugere går på samtidigt (og laver opdateringer), så tror jeg at du vil se en betragtelig fordel ved at skifte fra Access som er fil-baseret til en database-server til selve data.
Du kan sagtens fortsætte med din Access applikation og koble op via ODBC.
Om det skal være MS SQLServer, MySQL eller en anden database vil afhænge af hvad I har i huset, hvormange penge i har etc..
Tak for dit svar. Jeg forstår ikke at den ene bliver kaldt som fil mens den anden som IP. Kan du uddybe svaret og at dette er eneste forskel ? Jeg troede f.eks at SQL ville kunne låse på et lavere niveau og dermed stoppe konflikter mellem brugerne. Jeg håbede at SQL kunne stoppe mine nedbrud.
I lighed med øvrige brugere er jeg sikker på, at årsagen til disse nedbrud er, at du benytter Access til ting, den ikke er beregnet til.
Access er en desk top database, som ikke er beregnet til så mange brugere. Ganske vist påstår Miocrosoft, at der kan være op til 255 brugere, men i praksis er dette stærkt overdrevet. Jeg benytter Access som både front- og back end på min arbejdsplads. Der er ca 12 brugere, der samtidig foretager rettelser, men det er tydeligt at se, at db bliver langsommere jo flere brugere der er på.
Du bør bruge en SQL somBack end. Om det skal være MS SQLserver, MySQL er vel en smagssag. Men det vil helt sikkert løse dit problem.
Database via fil-adgang betyder at hver klientsidder og læser og opdaterer direkte i database filen. Det er langsomt over nettet for store database, giver store problemer med at kontrollere samtidighed (derfor hacket med LDB filen) og et nedbrud på en client maskinen kan resultet i korruot MDB fil.
Database via en database-server betyder, at klienten kun sender selve SQL sætningen til serveren og kun modtager svar data tilbage fra serveren. Det er kun serveren som læser/opdaterer database filen. Det er hurtigere fordi der skal flyttes færre data over nettet, det er langt nemmere at håndtere samtidigheds problemet fordi det kun er en som bruger filen og der sker intet med database filen hvis en klient går ned.
Mange tak for alle svarene. Jeg mangler således kun at få at vide hvor meget en sådan SQL base kan rumme og om der behov for fremtidige komprimeringer ? (Er den kun begrænset af serverens harddisk ?)
Komprimering af din SQL db ( nu snakker jeg SQL Server 2000 fra M$ ) sætter du serveren til selv at klare via en såkaldt 'Data maintainance plan' som også kan tage backup af din db i samme hug. Hvor meget din SQL db kan rumme ? Hvis du er tilfreds med det Access kan rumme, så behøver du ikke umiddelbart have nogen bekymringer :-) Til Arne_v vil jeg sige at det er min påstand at trafikken på nettet er meget afhængig af hvordan din applikatione er lavet. Det er end og meget nemt at lave noget rigtig skod-programmering der betyder at mange af fordelene ved SQL går op i røg. Men en god og optimeret applikation = godt resultat.
hugo> Jeg tror at for alle realitiske scenarier vil net-trafikken med en database-server vil være markant mindre end med en fil-database. Men selvføgelig er der forskel. Efter min mening er den største forskel dog at effektens absolutte værdi afhænger af dataenes størrelse. Hvis der fra fil-databasen skal hentes 5000 bytes og fra database-server 1000 bytes, så er der en faktor 5, men der er ingen mærkbar forskel for brugeren. 10 MB versus 5 MB er kun en faktor 2, men det kan mærkes af brugeren.
arne_v> jeg er grundlæggende enig i hvad du siger. Det jeg egentlig vil frem til er at hvis man ikke man samtidig begynder at tænke/designe på den for en SQL server rigtige måde, så vil investeringen ikke stå i forhold til udbyttet. Bare softwaren koster jo en hel del penge og skal man have noget fornyftigt hardware, så løber det jo hurtigt op. F.eks. så koster de min. 4 SCSI diske jo nemt adskillige tusinde kroner.
hugo> 15K RPM SCSI diske er jo en dejling ting. Men man kan da også have fornøjelse af en database-server på et par ganske almindelige IDE diske. Og MySQL har jo en fornuftig pris. :-)
arne_v> Hvad MySQL har eller ikke har skal jeg ikke kunne sige :-) har aldrig rodet med det. Har overvejet det, men har aldrig fået det gjort :-) For at køre en M$ SQL fornuftig, skal man bruge min. 4 diske - og det kan selvfølgelig godt være IDE, men .............................
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
