---

Hej
Jeg sidder og arbejder med et program der skal kunne fungere i et flerbruger
system. Programmet snakker med en Access-database som ligger på serveren.
Jeg har oplevet flere problemstillinger som jeg skal tage hensyn til.

1. Dataaccess er enormt langsom.

2. Ind imellem går en maskine ned og det kan opstå at databasen bliver
"korrupt". De andre brugere kan fint arbejde videre - men skal man logge på
med en ny bruger siger den "Reparér.." og det kan ikke lade sig gøre uden at
alle brugere logger ud.

3. Hvordan håndterer jeg bedst skrivninger (inkl. låsninger) til og fra
databasen? F.eks.
Bruger1 henter en ordre retter linie 2, 3 og 4 -
Bruger2 henter den samme ordre.
Bruger1 gemmer.
Bruger2 retter linie 1 og gemmer.
Nu er der iforhold til den oprindelige ordre kun rettet i linie 1. Da alle
data på ordren hentes ind i formen og alle data gemmes efterfølgende.
Ja - ugennemtænkt - og det er ikke mig der har påbegyndt det. Jeg skal bare
forsøge at afslutte det på bedst mulige måde.

Data sendes og hentes via
Set MyDataSet = MyDatabase.execute("Select * from.... ")

Mvh
Allan

---

Mon, 21 Jun 2004 11:18:41 +0200, > Allan < <ikke@nogetdukanbrugetil.noget>
skrev:

> Hej
> Jeg sidder og arbejder med et program der skal kunne fungere i et
> flerbruger
> system. Programmet snakker med en Access-database som ligger på serveren.
> Jeg har oplevet flere problemstillinger som jeg skal tage hensyn til.
>
> 1. Dataaccess er enormt langsom.
>
Kort sagt:

Et program på arbejdsstation med Access-database på server _er_ langsom.
Nothing doing (stort set).

Årsagen er den simple, at ved en 'Select * from xx where felt1 = 4' skal
_hele_ indholdet af _alle records_ i tabel1 hentes fra server til
arbejdsstation, idet det jo er arbejdsstationens CPU, der behandler ordren.

Det er naturligvis muligt ved små systemer, men bliver det blot lidt
komplicerede søgninger på en stor base, så kommer du ikke uden om, at det
mest effektive er en 'client/server-løsning, hvor SQL-ordrene afvikles på
serveren, og kun resultatet skal sendes via nettet til arbejdsstationen.


> 2. Ind imellem går en maskine ned og det kan opstå at databasen bliver
> "korrupt". De andre brugere kan fint arbejde videre - men skal man logge
> på
> med en ny bruger siger den "Reparér.." og det kan ikke lade sig gøre
> uden at
> alle brugere logger ud.
>

Bad luck


> 3. Hvordan håndterer jeg bedst skrivninger (inkl. låsninger) til og fra
> databasen? F.eks.
> Bruger1 henter en ordre retter linie 2, 3 og 4 -
> Bruger2 henter den samme ordre.
> Bruger1 gemmer.
> Bruger2 retter linie 1 og gemmer.
> Nu er der iforhold til den oprindelige ordre kun rettet i linie 1. Da
> alle
> data på ordren hentes ind i formen og alle data gemmes efterfølgende.

Du sætter en markering (flag) på ordren, når bruger 1 henter. Og sletter
flaget igen, når han har skrevet tilbage.
Bruger2 tester på flaget og få rbesked om, at 'En anden bruger redigerer i
øjeblikket den ønskede ordre'.

...du skal naturligvis huske at lave en rutine, der lægger flaget, hvis
bruger1 annullerer sin redigering uden at gemme




> Ja - ugennemtænkt - og det er ikke mig der har påbegyndt det. Jeg skal
> bare
> forsøge at afslutte det på bedst mulige måde.
>
Knæk og bræk...



Krabsen


> Data sendes og hentes via
> Set MyDataSet = MyDatabase.execute("Select * from.... ")
>
> Mvh
> Allan
>
--
Sendt via Opera.
www.krabsen.dk
www.responsnord.dk
mfl

---

> > 1. Dataaccess er enormt langsom.
> >
> Kort sagt:
>
> Et program på arbejdsstation med Access-database på server _er_ langsom.
> Nothing doing (stort set).

Tjaa - havde overvejet om brugeren ikke bare kunne afvikle programmet på
serveren via RDC (remote desktop connection) ... eller noget VPN måske.

> > 2. Ind imellem går en maskine ned og det kan opstå at databasen bliver
> > "korrupt". De andre brugere kan fint arbejde videre - men skal man logge
> > på
> > med en ny bruger siger den "Reparér.." og det kan ikke lade sig gøre
> > uden at
> > alle brugere logger ud.
>
> Bad luck

Ja... møg...

> > 3. Hvordan håndterer jeg bedst skrivninger (inkl. låsninger) til og fra
> > databasen? F.eks.
> > Bruger1 henter en ordre retter linie 2, 3 og 4 -
> > Bruger2 henter den samme ordre.
> > Bruger1 gemmer.
> > Bruger2 retter linie 1 og gemmer.
> > Nu er der iforhold til den oprindelige ordre kun rettet i linie 1. Da
> > alle
> > data på ordren hentes ind i formen og alle data gemmes efterfølgende.
>
> Du sætter en markering (flag) på ordren, når bruger 1 henter. Og sletter
> flaget igen, når han har skrevet tilbage.
> Bruger2 tester på flaget og få rbesked om, at 'En anden bruger redigerer i
> øjeblikket den ønskede ordre'.

Jo - den havde jeg egentlig tænkt på. Men hvad hvis brugeren åbner ordren og
programmet så går ned? Så kan der ikke pilles ved den ordre mere :-| Før der
er kørt en eller anden kørsel der rydder op...

Jeg ved at man via ADO kan benytte sig af noget
MyDB.BeginTrans
MyDB.CommitTrans
eller
MyDB.RollBackTrans -
det svarer vel nogenlunde til ttsbegin - ttscommit og ttsabort - men hvad
hvis der kaldes en BeginTrans og så går programmet ned? laver den så selv en
RollBackTrans efter et stykke tid?

Mvh
Allan

---

Allan skrev:
> Jeg sidder og arbejder med et program der skal kunne fungere i et
flerbruger
> system. Programmet snakker med en Access-database som ligger på serveren.
> Jeg har oplevet flere problemstillinger som jeg skal tage hensyn til.

Husk at Access skal opfattes som et enkelt-bruger "lege"-databasesystem.
Hvis man bruger Access til andet, er man "selv ude om det", hvis det kommer
til at virke a h...... til.

Rent principielt på og papiret kan Access naturlig godt bruges til meget
mere, men hele den grundlæggende måde Access arbejder på, gør den meget lidt
velegnet til flerbruger/netværksløsninger.

-------
Tomas

---

> > Jeg sidder og arbejder med et program der skal kunne fungere i et
> flerbruger
> > system. Programmet snakker med en Access-database som ligger på
serveren.
> > Jeg har oplevet flere problemstillinger som jeg skal tage hensyn til.
>
> Husk at Access skal opfattes som et enkelt-bruger "lege"-databasesystem.
> Hvis man bruger Access til andet, er man "selv ude om det", hvis det
kommer
> til at virke a h...... til.
>
> Rent principielt på og papiret kan Access naturlig godt bruges til meget
> mere, men hele den grundlæggende måde Access arbejder på, gør den meget
lidt
> velegnet til flerbruger/netværksløsninger.

Tjaaa - Det vidste jeg egentlig godt. Ville da også helst have lavet en
3-tier løsning med en MS SQL base... Men sådan så projektet bare ikke ud da
jeg overtog det. Det skulle bare lige færdiggøres... Alt er kodet med alm.
Execute("Sql statement")...
Det giver problemer ved f.eks. opdatering af nogle forudsætninger på nogle
vare. Der skal disse forudsætninger gemmes på de allerede oprettede
ordrelinier - også...

Så hvis man ændre "forudsætningerne" og ordrelinierne bliver opdateret - og
"forudsætningerne" IKKE gemmes fordi programmet går ned midt i processen...
Så kan der ikke laves rollback... (ttsabort)... møg... Mon det kan betale
sig at flytte det over på en SQL (MSDE) ? Hmnn..

tja..

Mvh
Allan

---

Allanskrev:
> Tjaaa - Det vidste jeg egentlig godt. Ville da også helst have lavet en
> 3-tier løsning med en MS SQL base... Men sådan så projektet bare ikke ud
da
> jeg overtog det. Det skulle bare lige færdiggøres...

Nå, ja, men så kan du i det mindste føle dig lidt "hellig" (forstået som
"sådan ville _jeg_ ikke have gjort"), hvis det kan bruges til noget...

> Så kan der ikke laves rollback... (ttsabort)... møg... Mon det kan betale
> sig at flytte det over på en SQL (MSDE) ? Hmnn..

Hvis pengetanken er meget begænset, hvad med at kigge på en Linux med én
eller anden form for gratis database på? Det kræver selvfølgelig at man har
noget HW til rådighed.

En anden ting forekommer mig: Der er noget med at man kan få Access til at
være bedre til flerbrugersituationen, hvis man kører ODBC op mod en central
computer med Access'en på. Har ikke prøvet det selv, men har fået det
fortalt engang for ca. 3 år siden. Hukommelsen er ikke hvad den aldrig har
været, så jeg kan ikke huske de præcise detaljer sådan lige på siddende
balle.

-------
Tomas

---

> Hvis pengetanken er meget begænset, hvad med at kigge på en Linux med én
> eller anden form for gratis database på? Det kræver selvfølgelig at man
har
> noget HW til rådighed.

Njaaa... Så koster vedligeholdelsen penge jo... Så hellere kaste de 8 -
10.000 kr. efter en MS SQL..
Hmnn - Det ender sgu nok med en SAP Business One - med lidt tilretninger på
i stedet. Hvis det da nogensinde skal køre stabilt

> En anden ting forekommer mig: Der er noget med at man kan få Access til at
> være bedre til flerbrugersituationen, hvis man kører ODBC op mod en
central
> computer med Access'en på. Har ikke prøvet det selv...

Det er skam det jeg bruger her... Alm. fil-dsn forbindelse.
Sløvt...

Mvh
Allan

---

Allan skrev:

> Tjaaa - Det vidste jeg egentlig godt. Ville da også helst have lavet en
> 3-tier løsning med en MS SQL base... Men sådan så projektet bare ikke
> ud da jeg overtog det. Det skulle bare lige færdiggøres... Alt er kodet
> med alm. Execute("Sql statement")...
>
> ... Mon det kan betale sig at flytte det over på en SQL (MSDE) ? Hmnn..

Hvis det skal bruges af mange i lang tid fremover: absolut ja.

Hvis det er en stor opgave, kan du evt. købe hjælp hos os til
at automatisere dele af processen - vi har en vis erfaring med
præcis den slags omlægninger som du beskriver, og har en del
værktøjer at takle det med.

Ole Nielsby, Teknologisk Institut.

---

> > Tjaaa - Det vidste jeg egentlig godt. Ville da også helst have lavet en
> > 3-tier løsning med en MS SQL base... Men sådan så projektet bare ikke
> > ud da jeg overtog det. Det skulle bare lige færdiggøres... Alt er kodet
> > med alm. Execute("Sql statement")...
> >
> > ... Mon det kan betale sig at flytte det over på en SQL (MSDE) ? Hmnn..
>
> Hvis det skal bruges af mange i lang tid fremover: absolut ja.
>
> Hvis det er en stor opgave, kan du evt. købe hjælp hos os til
> at automatisere dele af processen - vi har en vis erfaring med
> præcis den slags omlægninger som du beskriver, og har en del
> værktøjer at takle det med.

Tjjaa - Det er da mægtigt pænt af dig. Men så stort er projektet heller
ikke. Jeg kan se ca. 100 timer på at skrive det om - måske lidt færrere.
Jeg tror det bedre ville kunne svare sig at kaste en SAP SBO efter det. Den
ligger på lige omkring 10K pr. bruger - og med 4 brugere på - så er der
stadig 60 timer til tilretninger... Det tror jeg i det hele taget vil
fungere meget bedre.

Mvh
Allan Rasmussen
System udvikler