Access som brugerflade til mindre SQL-db

Det er rigtigt, at du kan lave en PROTOTYPE på en SQL Server database i Access, men dertil og ikke længere. SQL Server er langt mere avanceret database end Access, og du får kun fuldt udbytte af SQL Serveren og dens muligheder ved at starte databasen direkte i SQL Server.

Selv Access som front end til SQL Server er et problem.

Det er jo netop Access som front end til SQL Serveren jeg havde tænkt, men hvad er problemet så i det?

Som sådan tror jeg ikke der er behovet for at udnytte de avancerede ting i SQL-serveren. Det er som sagt en mindre database der er tale om - årsagen til at vi vil bruge SQL-serveren er som sagt udelukkende at det er et krav at data ligger der. Havde det ikke været et krav tror jeg vi kunne have nøjedes med en access-db.

Deri er jeg helt uenig. Jeg har mange års erfaring med at udvikle applikationer i Access op mod SQL server (og også Oracle for den sags skyld), og jeg mener at access er t fremragende udviklingsværktøj til dette. Hvis du ser bort fra, at en Access-database 'slæber' rundt på Access-programmet, så kan du jo i princippet det samme i Access, som du kan i f.eks VB. Mange ting er bare mange gange hurtigere at udvikle i Access frem for i andre "lav-generations'-værktøjer.

Med en databaseserver som backend, så har du hele kraften fra client/server-teknologien sammen med brugervenligheden i Access.

Men hvis udviklingsomkostningerne ikke er afgørende eller hvis der er mange samtidige brugere (>100-200), så ville jeg måske vælge C# eller Delphi.
Ellers ser jeg ingen grund til, ikke at bruge Access.

Jeg vil endda lade som om, jeg slet ikke så sætningen "Eller om vi bør få lavet et "rigtigt" program til at håndtere det" ;o)

Du kan godt benytte Access som front end til SQL, men ud over at man generelt ikke anbefaler dette, har jeg ikke de helt store erfaringer.

Du skal oprettet et nyt projekt (*.adp) i Access. Her vælger du ny database i stedet for eksisterende data

You should try using Access Data Projects (ADP) instead of MDB. There are many advantages with this although if you are used to MDB there are a number of differences.
You can also link your SQL Server tables into your Access (MDB) using an ODBC data connection

ADP er et kraftigt værktøj, som giver den optimale udnyttelse af en MS SQL Server. Men hvis du påtænker at benytte Oracle (nu eller senere), så duer det ikke. Så skal du vælge ODBC-løsningen og alm. .mdb

ADP kender jeg intet til - hvad er det? Hvor kan jeg finde lidt læsestof om det?

Der påtænkes ikke at skifte til oracle - oracle var egentlig bare en mulighed på lige fod med SQL, da kravet blot er at data skal ligge på en af vores databaseservere(Som er enten Oracle eller SQL). Jeg kender så bare mest til SQL.

thomas > Ja, der var jo en grund til at jeg brugte " om "rigtigt" program :-)

Hvordan vil en brugerstyring/forskellige rettigheder kunne håndteres i forbindelse med Access som frontend til SQL?

ADP er blot en anden Access-filtype, som connecter direkte til SQL serveren. Dvs at du arbejder med views, stored procedures, triggers m.m. direkte fra Access. Du "mister" så dine alm. forespørgsler, ligesom du ikke længere kan bruge felt/formular-referencer i dine views.

Rettigheder angivet på SQL serveren (til tabellerne) vil jo slå gennem i Access. Dvs, at brugeren skal/kan logge på SQL serveren samtidig med at han starter applikationen op.

Ellers har Access sit eget sikkerhedssytem, som er mere velegnet til at lave brugerstyring. Læs evt min artikel om Access sikkerhed: http://www.eksperten.dk/artikler/314?Esession=38a07e9cb0a24391fb4344fa162612ac

Du er tilgivet mht den med "rigtigt" program ;o)

Thomas -> Jeg har faktisk benyttet mig af din artikel tidligere(Iøvrigt en MEGET god artikel!!!), men kunne ikke lige gennemskue hvordan det fungerede når nu man kører med SQL som backend. Jeg har tidligere sat rettighederne på Backend i forbindelse med en opdelt Access. Når man så benytter SQL, skal man så sætte rettighederne på SQL? Denne kan vel ikke på samme måde kobles op på an arbejdsgruppe-fil?

tak for de pæne ord :o)

Det er korrekt, at når man bruger SQL server som backend, så er der lidt andre regler, som træder i kraft.

Det er altid backendens sikkerhed, som er bestemmende. I dette tilfælde SQL serveren. Men derfor kan man godt lægge sin egen sikkerhed oven på dette lag, således at formularer, rapporter m.m. kan styres afhængig af brugeren.

Nogle vælger at tilgå SQl tabellerne med én og samme bruger (f.eks. "sa", som er standard-brugeren på SQl serveren), men styre hele sikkerheden på Access-frontenden. Dette er kun tilrådeligt, hvis der ikke er tale om følsomme data, da man i så fald jo bare kan connect fra en anden applikation og derved få uhindret adgang til data.

Det lyder jo umiddelbart til at access er en oplagt løsning til det her projekt.

Så er spørgsmålet bare stadigvæk om det skal være ADP eller MDB? Jeg har som sagt ikke kendskab til ADP og vil gerne have nogle links til lidt informationer/vejledninger/tutorials.

Ellers er i velkomne til alle 3 at smide et svar så i kan få jeres velfortjente point...

Lad bare Thomas få min andel :o)

Jensen, du er blevet så beskeden på det sidste...få nu, hvad du fortjener :o)

Mikkel-> jeg har ikke lige noget link, men du kan læse en del om det i online-hjælpen i Access. Derudover kan jeg anbefale "Access Developers Handbook - Enterprise", som er biblen over dem alle. Men det er måske lidt overkill, hvis du bare vil have et lille indblik.

Ellers prøv dig lidt frem: opret ny database og vælg "Access Data Projekt" og angiv herefter din SQL server.

Thomas > jeg er holdt op med at være så aktiv herinde, så det er fuldt fortjent at du får alle point :o)

You keep them Thomas, dont want Charlotte on my heals :o)

Så siger vi det :-)
Jeg takker i hvert tilfælde jer alle tre for jeres indlæg!!!