Split acces til MS sql server, men stadig med Acces som frontend

Lad mig sige det på den måde: man kan gøre det, men nemt er det ikke nødvendigvis.
Man kan gøre det via en ODBC forbindelse eller man kan lave den forkromede løsning og lave applikationen om til en ADP fil.

Der kan siges for og imod begge løsninger. Hvis koden i applikationen ellers er forberedt på det, er ODBC nok den nemmeste/hurtigste løsning. Men den bedste er efter min bedste overbevisning ADP løsningen. Men da det f.eks. kræver at alle queries laves om enten til views eller stored procedures på SQL serveren, så kan det være meget tidskrævende.

Ok.

Jeg havde overvejet at foreslå kunden at imporetere dataene ind i SQL databasen, og så lave en ny webbaseret frontend, og så lave rapporterne via MS reporting services. Da de også har en sharepoint løsning, kunne både rapporter og dataindtastning så ligges ind der. Vil det være hul i hovedet?

Jeg kender overhovedet ikke noget til Sharepoint, så det skal jeg ikke kunne sige.

Access har en udmærket guide, der kan opgradere til SQL server - endda på flere levels

Funktioner | Databasefunktioner | Guiden databasekonvertering.

Det vigtigste er, når du skal svare på "Hvilke programændringer vil du foretage" - der skal du vælge "Sammenkæd SQL-servertabeller med eksisterende program". Så får du en Accessdatabase som du kender det - med linkede tabeller til SQL-serveren.

Det er vigtigt, at du gennemgår dine tabeller grundigt, inden du foretager konverteringen. SQL-server er mere kritisk end Access med visse ting. Alle datofelter skal indeholde gyldige datoer - der må ikke ligge noget 'miskmask fra gammel tid'. Alle tabeller skal have en unik-nøgle.

Hvis du ændrer i dine unik-nøgler, er det vigtigt at du tjekker de forespørgsler, hvor de ændrede tabeller indgår - jeg har ved flere lejligheder opdaget, at forespørgslerne går fra at være opdaterbare til at være ikke-opdaterbare. En ændring af relationerne mellem tabellerne vil ofte løse det problem.

Du kan undervejs vælge hvilke tabeller, der skal konverteres. Vær kritisk, og medtag kun de nødvendigste tabeller. Når du laver denne konvertering, kan du efterfølgende kopiere .mdb-filen, så hver bruger har en .mdb-fil (front-end) på lokalt drev - det giver som regel bedste performance. Derfor skal du ikke konvertere de tabeller som indeholder brugerrelaterede oplysninger, som fx. temporere tabeller - lad dem ligge lokalt.

Tag en kopi af dabasen først og brug kopien til at konvertere med. Hvis det går galt, kan man slette databasen på SQL serveren (via serverens Enterprise Manager), slette kopien af databasen og starte forfra.

Det lyder rigtigt godt.

Opgaven er dog blevet nedprioteret lidt, og jeg skal først i gang med den om ca. 1 mdr.

Men i skal have tak for hjælpen.

Smider du også et svar Hugo? Så får i begge point.

Nå, har set applikationen, og har besluttet ikke at splitte den op.

Hugo du får lige en dag til at nå at smide et svar. Så får i begge point.

Det vil ikke hjælpe at jeg lægger et svar på et lukket spørgsmål :-)

Har lige lukket det tidligere i dag.