---

Hej.

Spørgsmålet er måske ikke så simpelt, men i hovedtræk: Hvad skal man
være OBS og samt gøre anderledes, hvis man vil have sit program til at
virke i et fler-bruger miljø?

Man hører tit folk sige, "Husk nu at være opmærksom på, om det kan køre
med flere brugere" men hvad dækker det over.

---

Michael Sørensen wrote:

> Man hører tit folk sige, "Husk nu at være opmærksom på, om det kan køre
> med flere brugere" men hvad dækker det over.

Det dækker over brugen af fælles data.
Hvis det f.eks. er et program til vedligeholdelse af kunder, skal man sikre
sig, at nogle måske ikke har adgang, andre kan se, men ikke rette, og
andre kan oprette/rette.

Endvidere skal man via låsninger eller lign. sikre sig, at der ikke er to
der retter det samme på samme tid.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Michael Sørensen wrote:
>
>> Man hører tit folk sige, "Husk nu at være opmærksom på, om det kan køre
>> med flere brugere" men hvad dækker det over.
>
> Det dækker over brugen af fælles data.
> Hvis det f.eks. er et program til vedligeholdelse af kunder, skal man sikre
> sig, at nogle måske ikke har adgang, andre kan se, men ikke rette, og
> andre kan oprette/rette.
>
> Endvidere skal man via låsninger eller lign. sikre sig, at der ikke er to
> der retter det samme på samme tid.

Hej Stig.

Tak for dit svar. Det var lærerigt.

Delen omkring sikring af brugergrupper mht. adgang osv. ser ud til at
være til at gå til.

Har du mulighed for at skitsere et eksempel på afsnittet omkring låsning.

Jeg kan sagtens følge tankegangen i ideen, men hvordan det gøres i
praksis er jeg bange for, at jeg mangler.

---

Michael Sørensen wrote:

> Har du mulighed for at skitsere et eksempel på afsnittet omkring låsning.
>
> Jeg kan sagtens følge tankegangen i ideen, men hvordan det gøres i
> praksis er jeg bange for, at jeg mangler.

Det kommer helt an på hvilke data - og databaser, der er tale om, og er
formentlig individuelt for de givne applikationer.

Hvis det er flade filer som man brugte i 'oldtiden', så findes der noget
lock/unlock.

Nogle desktop databaser har det vist også, men de er generelt ikke gode til
flerbrugersystemer (Paradox,Access og den dur).

Rigtige databser har ikke et egentlig lock directive, men her bruger man
typisk:
begintrans
- opdater noget
- opdater noget mere
if dataOK then
committrans
else
rollbacktrans

Gennem de sidste 25 år (for mit vedkommende) har diskussionen så været eks:
Hvad hvis bruger A henter en kunde til rettelse, og bruger B henter den
samme til rettelse.

Her kommer det subjektive ind, hvor jeg mener at hvis det kan lade sig gøre,
så har man et problem med sin forretningsgang, og derfor plejer jeg at lave
det så den sidste 'får ret' - dvs begge får rettet, men den sidste
overskriver den anden.

Nogle databaser kan lave en sådan lock, og jeg har også set systemer hvor
det er brugt (Maconomy f.eks.).

Her er det rigtig sjovt nå en bruger har hentet noget på sin skærm, og er
gået til frokost

Man kan sagtens lave noget pseudo lock ved at indføre et felt på tabellen,
eks. islocked, og teste på dette ved hent af en record.

Hvis man gør det, skal man huske at lave en facilitet, så 'låsninger' kan
slettes, da uaftoriseret nedlukning af et program vil efterlade orphan
'locks'.

Men den fundamentale problemstiling er det med opdatering af flere tabeller.
For at illustrere, kan vi tage udgangspunkt i en konto og posteringer.

For hver transaktion skal saldoen opdateres på kontoen, og en postering
indsættes.

Her skal enten begge ske, eller ingen, for ellers stemmer tingene ikke.

Det er i disse situationer begintrans/commit kommer ind i billedet, for de
sørger for
1) Enten alt eller intet bliver udført
2) Der er ikke 2 brugere, der kan udføre samme transktion på samme tid
(implicit låsning).

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Michael Sørensen wrote:
>
>> Har du mulighed for at skitsere et eksempel på afsnittet omkring låsning.
>>
>> Jeg kan sagtens følge tankegangen i ideen, men hvordan det gøres i
>> praksis er jeg bange for, at jeg mangler.
>
> Det kommer helt an på hvilke data - og databaser, der er tale om, og er
> formentlig individuelt for de givne applikationer.
>
> Hvis det er flade filer som man brugte i 'oldtiden', så findes der noget
> lock/unlock.
>
> Nogle desktop databaser har det vist også, men de er generelt ikke gode til
> flerbrugersystemer (Paradox,Access og den dur).
>
> Rigtige databser har ikke et egentlig lock directive, men her bruger man
> typisk:
> begintrans
> - opdater noget
> - opdater noget mere
> if dataOK then
> committrans
> else
> rollbacktrans
>
> Gennem de sidste 25 år (for mit vedkommende) har diskussionen så været eks:
> Hvad hvis bruger A henter en kunde til rettelse, og bruger B henter den
> samme til rettelse.
>
> Her kommer det subjektive ind, hvor jeg mener at hvis det kan lade sig gøre,
> så har man et problem med sin forretningsgang, og derfor plejer jeg at lave
> det så den sidste 'får ret' - dvs begge får rettet, men den sidste
> overskriver den anden.
>
> Nogle databaser kan lave en sådan lock, og jeg har også set systemer hvor
> det er brugt (Maconomy f.eks.).
>
> Her er det rigtig sjovt nå en bruger har hentet noget på sin skærm, og er
> gået til frokost
>
> Man kan sagtens lave noget pseudo lock ved at indføre et felt på tabellen,
> eks. islocked, og teste på dette ved hent af en record.
>
> Hvis man gør det, skal man huske at lave en facilitet, så 'låsninger' kan
> slettes, da uaftoriseret nedlukning af et program vil efterlade orphan
> 'locks'.
>
> Men den fundamentale problemstiling er det med opdatering af flere tabeller.
> For at illustrere, kan vi tage udgangspunkt i en konto og posteringer.
>
> For hver transaktion skal saldoen opdateres på kontoen, og en postering
> indsættes.
>
> Her skal enten begge ske, eller ingen, for ellers stemmer tingene ikke.
>
> Det er i disse situationer begintrans/commit kommer ind i billedet, for de
> sørger for
> 1) Enten alt eller intet bliver udført
> 2) Der er ikke 2 brugere, der kan udføre samme transktion på samme tid
> (implicit låsning).
>

Hej Stig.

Jeg siger endnu engang tak for et lærerigt svar.

Michael.

---

"Michael Sørensen" <Spam@nej.tak> skrev i en meddelelse
news:4b2fb847$0$8550$ba624c82@nntp06.dk.telia.net...
> Stig Johansen skrev:
>> Michael Sørensen wrote:
>>
>>> Har du mulighed for at skitsere et eksempel på afsnittet omkring
>>> låsning.
>>>
>>> Jeg kan sagtens følge tankegangen i ideen, men hvordan det gøres i
>>> praksis er jeg bange for, at jeg mangler.
>>
>> Det kommer helt an på hvilke data - og databaser, der er tale om, og er
>> formentlig individuelt for de givne applikationer.
>>

Da jeg rodede med systemer a la det beskrevne, havde vi en anden løsning,
der var dikteret af det faktum at vores maskine (en IBM 360/40) kun havde
128K hukommelse, og 4x 7.25MB diskplads. Der var altså ikke plads for SQL
tabeller eller tilsvarende.
Vi brugte index-sequentielle filer, der blev opdateret om natten og dermed
implicit var urørlige om dagen. Opdateringer klaredes ved at lave 1 record
per opdatering, og så blev recorden skrevet "ved siden af". Man skrev
naturligvis kun de felter der skulle opdateres. Dette gjorde så, at flere
kunne opdatere samtidig, så længe de ikke rettede i samme felt. Når man så i
løbet af dagen skulle lave et opslag, kiggede man først i den
index-sequentielle fil, og så lkiggede man i filen med opdateringer, der
iøvrigt også var indexeret. Så kørte man det hele sammen om natten in et
batch-job. Fungerede fortræffeligt.

Nico

---

Nico de Jong wrote:

> Da jeg rodede med systemer a la det beskrevne, havde vi en anden løsning,
> der var dikteret af det faktum at vores maskine (en IBM 360/40) kun havde
> 128K hukommelse, og 4x 7.25MB diskplads. Der var altså ikke plads for SQL
> tabeller eller tilsvarende.
> Vi brugte index-sequentielle filer, der blev opdateret om natten og dermed
> implicit var urørlige om dagen.

Det må vist være fortid.
Jeg har de sidste ca. 30 år brugt HP's IMAGE (netværksdatabase).
Det er heller ikke SQL baseret, men med primitiver som:
DBLOCK(...
DBGET(..
vis skærm
læs skærm
DBUPDATE(...
DBUNLOCK(...

Dog bruger jeg ikke denne metodik, for det giver netop problemstillingen med
at en lås er udtaget i alt for lang tid mellem vis og læs skærm (specielt
hvis brugeren går til frokost).

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
news:4b304793$0$271$14726298@news.sunsite.dk...
> Nico de Jong wrote:
>
>> Da jeg rodede med systemer a la det beskrevne, havde vi en anden løsning,
>> der var dikteret af det faktum at vores maskine (en IBM 360/40) kun havde
>> 128K hukommelse, og 4x 7.25MB diskplads. Der var altså ikke plads for SQL
>> tabeller eller tilsvarende.
>> Vi brugte index-sequentielle filer, der blev opdateret om natten og
>> dermed
>> implicit var urørlige om dagen.
>
> Det må vist være fortid.

Enig. Jeg taler her om slutningen af 60'erne. Der fandtes databasesystemer,
men de var yderst begrænsede og kun kunne køre ordentligt på maskiner med
mindst 256K. Jeg tænker her på BOMP (Bill Of Material Processor *), DBOMP,
og forfaderen til DL/I, der pudsigt nok også hed DL/I. Ja, I griner nok nu,
men den mindste maskine jeg har brugt, stod hos Dansk Arbejdsgiverforening.
Den var på hele 28K, og var en 360/25 med 2 harddiske (7,25 MB hver) og 4
tapestationer. Så skulle jeg lave løn- og mandtalsstatistik, og så fik jeg
bevilget udviddelse af hukommelsen med hele 4 (fire) K. Og det var dengang
man _lejede_ hukommelse. Så kunne jeg også lave histogrammer på en
linieprinter (IBM 1403).

* BOMP håndterede styklister, men kun til (svjh) 3 niveauer ned.

Nico

---

Nico de Jong wrote:

> Enig. Jeg taler her om slutningen af 60'erne. Der fandtes
> databasesystemer, men de var yderst begrænsede og kun kunne køre
> ordentligt på maskiner med mindst 256K. Jeg tænker her på BOMP (Bill Of
> Material Processor *), DBOMP, og forfaderen til DL/I, der pudsigt nok også
> hed DL/I. Ja, I griner nok nu,

Nej, jeg griner ikke.
Et af mine første projekter (inden for denne genre) var netop at lave
styklistenedbrydning, eller 'Bill Of Material', og efterfølgende rollup.

Rollup skulle bruges for at beregne materialeomkostninger (og
produktionesomkostninger) under givne forudsætninger.

I det projekt var det COBOL, og der var udfordringen at lave en rekursiv
'stack'.


--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
news:4b30a01f$0$279$14726298@news.sunsite.dk...
> Nico de Jong wrote:
>
>> Enig. Jeg taler her om slutningen af 60'erne. Der fandtes
>> databasesystemer, men de var yderst begrænsede og kun kunne køre
>> ordentligt på maskiner med mindst 256K. Jeg tænker her på BOMP (Bill Of
>> Material Processor *), DBOMP, og forfaderen til DL/I, der pudsigt nok
>> også
>> hed DL/I. Ja, I griner nok nu,
>
> Nej, jeg griner ikke.
> Et af mine første projekter (inden for denne genre) var netop at lave
> styklistenedbrydning, eller 'Bill Of Material', og efterfølgende rollup.
>
> Rollup skulle bruges for at beregne materialeomkostninger (og
> produktionesomkostninger) under givne forudsætninger.
>
> I det projekt var det COBOL, og der var udfordringen at lave en rekursiv
> 'stack'.
>
>
Det med at grine var ikke møntet på dig, men på de yngre folk der læser med.
Jeg brugte også Cobol på det projekt, blandet med en pæn portion Assembler.
Der skulle jo spares på hukommelsen
Den dag idag gør det billedligt talt ondt, når jeg ser hvordan der svines
med hukommelsen, og hvor ineffektivt der kodes, men det er jo en helt anden
historie.

Nico

---

Nico de Jong wrote:

> Den dag idag gør det billedligt talt ondt, når jeg ser hvordan der svines
> med hukommelsen, og hvor ineffektivt der kodes, men det er jo en helt
> anden historie.

Du er ikke alene.
Jeg tænker nogle gange på hvordan man måtte kode effektivt for at have 200+
brugere kørende samtidigt på en 'kværn' med 8MB (ja 8*MB*) hukommelse.

Desværre er det nok en glemt disciplin, for der er jo 'hukommelse nok' og
'power nok', for det 'koster ingenting'.

Men det har medført uhørt stort strømforbrug osv...

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
news:4b30b4e4$0$275$14726298@news.sunsite.dk...
> Nico de Jong wrote:
>
>> Den dag idag gør det billedligt talt ondt, når jeg ser hvordan der svines
>> med hukommelsen, og hvor ineffektivt der kodes, men det er jo en helt
>> anden historie.
>
> Du er ikke alene.
> Jeg tænker nogle gange på hvordan man måtte kode effektivt for at have
> 200+
> brugere kørende samtidigt på en 'kværn' med 8MB (ja 8*MB*) hukommelse.
>
> Desværre er det nok en glemt disciplin, for der er jo 'hukommelse nok' og
> 'power nok', for det 'koster ingenting'.
>
> Men det har medført uhørt stort strømforbrug osv...
>
> --
Helt enig, igen. Måske burde sådan noglen gamle r...... som os skrive en bog
om det, krydret med anekdoter fra det virkelige liv.

Nico

---

"Nico de Jong" <nico@farumdata.dk> skrev i en meddelelse
news:7pbsc8FtuaU1@mid.individual.net...
> "Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
> news:4b30b4e4$0$275$14726298@news.sunsite.dk...
KLIPPET
> Helt enig, igen. Måske burde sådan noglen gamle r...... som os skrive en
> bog om det, krydret med anekdoter fra det virkelige liv.
>
> Nico
Det er nu hyggeligt at 'høre' på den slags nostalgi!
Jeg er køber til jeres bog.
Mvh Kurt

---

Kurt G wrote:

> Det er nu hyggeligt at 'høre' på den slags nostalgi!
> Jeg er køber til jeres bog.

Hvis jeg skulle skrive en bog om hvad jeg har rodet med af EDB de sidste 30
år, og det tager 3 gange så lang tid at skrive, så vil den først udkomme i
år 2100 :)

--
Med venlig hilsen
Stig Johansen

---

"Nico de Jong" <nico@farumdata.dk> wrote in message
news:7pbp9gFctqU1@mid.individual.net...
>
> Det med at grine var ikke møntet på dig, men på de yngre folk der læser
> med.

Der er sgu' da ingen yngre folk i en pascal-gruppe.....

---

"Uffe Kousgaard" <oh@no.no> skrev i en meddelelse
news:4b30c749$0$271$14726298@news.sunsite.dk...
> "Nico de Jong" <nico@farumdata.dk> wrote in message
> news:7pbp9gFctqU1@mid.individual.net...
>>
>> Det med at grine var ikke møntet på dig, men på de yngre folk der læser
>> med.
>
> Der er sgu' da ingen yngre folk i en pascal-gruppe.....

27 år og allerede gammel