---

Har lige haft en mindre diskussion (igen) med min søn ingeniøren.
Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
data,.....siger han. Så meget som jeg holder af ham, er det mig
inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
Er der nogen der har et par argumenter til næste gang vi mødes?
mvh
Erling

---

eh-dh@mail.dk (Erling Hansen) writes:

> Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
> Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
> data,.....siger han. Så meget som jeg holder af ham, er det mig
> inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
> Er der nogen der har et par argumenter til næste gang vi mødes?
> mvh

Prøv du at installere Google Desktop og leg lidt med det.

Da det fås til både PC og Mac skulle diskussionen gerne ende med
uafgjort :)
--
Thorbjørn Ravn Andersen "... plus ... Tubular iMacs!"

---

Erling Hansen wrote:
> Har lige haft en mindre diskussion (igen) med min søn ingeniøren.
> Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
> Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
> data,.....siger han. Så meget som jeg holder af ham, er det mig
> inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
> Er der nogen der har et par argumenter til næste gang vi mødes?

Hvis han tænker på MS Access, så er det da noget af det værste gang
bras, der nogensinde er lavet. Det er ustabilt, uhandy og fyldt med
alvorlige fejl i selve basekernen. Desuden er Access end ikke kompatibel
med hverken Firefox, Camino, SeaMonkey, Netscape eller Opera. Den kan
kun arbejde sammen med Explorer. Desuden er der uhyggelige mangler i
sådan noget som Unicode understøttelse. De 'plug-ins', som MS laver til
andre baseprogrammer, lider af manglende kompatibilitet og er meget
langsomme i brug.

Tager du derimod de andre rigtig store databaser - Filemaker Pro, 4th
Dimension og opensource baserne SQL og MySQL, så er der overhovedet
ingen forskel hverken i programmernes muligheder eller i kompatibilitet
- hverken på Mac eller Windows.

Mine erfaringer er, at en velkonstrueret database i Filemaker sat op mod
en tilsvarende MSAccess, så er det helt klart Filemaker, der er den
hurtigste.

Selvfølgelig kommer det an på hele konstruktion og optimering, men hvis
vi har to 100% optimerede baser i Filemaker og Access, så vinder
Filemaker med flere hestelængder på en Mac mod en PC. Hvis man bruger en
100% optimeret Filemaker base i både Mac og Win versionen på hver sin
maskine, er der overhovedet ingen forskel.

En væsentlig ting, man (endnu) ikke kan i Access, er fx. at kunne søge i
en fuldstændig lukket FMP base fra et andet sted end dér, hvor FMP basen
er placeret. Filemaker laver en plugin til Access, der gør det muligt at
kunne importere og/eller læse data fra visse dele af en lukket FMP base
på en Access-baseret computer. Men MS vil ikke frigive de koder, der
skal til for at plugin'en kan blive 100% kompatibel med Access. - Og så
er det altså flintrende ligegyldigt, om FMP basen befinder sig på en Mac
eller en Wintel.

Så min konklusion er, at der ingen forskel er overhovedet.

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rgds. Grüße, Mvh. Erik Richard Sørensen, Member of ADC
<mac-man_NOSP@M_stofanet.dk> <http://www.nisus.com>
NisusWriter - The Future In Multilingual Textprocessing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen skrev:

>> Har lige haft en mindre diskussion (igen) med min søn ingeniøren.
>> Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
>> Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
>> data,.....siger han. Så meget som jeg holder af ham, er det mig
>> inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
>> Er der nogen der har et par argumenter til næste gang vi mødes?
>
> Hvis han tænker på MS Access, så er det da noget af det værste gang
> bras, der nogensinde er lavet.

Access er glimrende til det det er lavet til.

> Det er ustabilt, uhandy og fyldt med
> alvorlige fejl i selve basekernen.

Det kan ikke være meget erfaring du har med det.

> Desuden er Access end ikke kompatibel
> med hverken Firefox, Camino, SeaMonkey, Netscape eller Opera.

Det er der heller ikke andre databaser der er. Webbrowsere taler med
webservere, ikke databaser.

> Den kan
> kun arbejde sammen med Explorer. Desuden er der uhyggelige mangler i
> sådan noget som Unicode understøttelse.

Access lagrer al data som unicode.

> De 'plug-ins', som MS laver til
> andre baseprogrammer, lider af manglende kompatibilitet og er meget
> langsomme i brug.
>
> Tager du derimod de andre rigtig store databaser - Filemaker Pro, 4th
> Dimension og opensource baserne SQL og MySQL, så er der overhovedet
> ingen forskel hverken i programmernes muligheder eller i kompatibilitet
> - hverken på Mac eller Windows.

Filemaker er ikke en rigtig stor database.

> Mine erfaringer er, at en velkonstrueret database i Filemaker sat op mod
> en tilsvarende MSAccess, så er det helt klart Filemaker, der er den
> hurtigste.

Du må gerne prøve at bilde dig selv ind at du har set et gyldigt
tetscenarie.

> Selvfølgelig kommer det an på hele konstruktion og optimering, men hvis
> vi har to 100% optimerede baser i Filemaker og Access, så vinder
> Filemaker med flere hestelængder på en Mac mod en PC. Hvis man bruger en
> 100% optimeret Filemaker base i både Mac og Win versionen på hver sin
> maskine, er der overhovedet ingen forskel.
>
> En væsentlig ting, man (endnu) ikke kan i Access, er fx. at kunne søge i
> en fuldstændig lukket FMP base fra et andet sted end dér, hvor FMP basen
> er placeret.

Hvordan får du det til en væsentlig ting?

> Filemaker laver en plugin til Access, der gør det muligt at
> kunne importere og/eller læse data fra visse dele af en lukket FMP base
> på en Access-baseret computer. Men MS vil ikke frigive de koder, der
> skal til for at plugin'en kan blive 100% kompatibel med Access.

Filemaker kan bare implementere ordentlig ODBC-understøttelse, så er den
ged barberet.

> - Og så
> er det altså flintrende ligegyldigt, om FMP basen befinder sig på en Mac
> eller en Wintel.
>
> Så min konklusion er, at der ingen forskel er overhovedet.

Forskellen er at der er et hav af små databaser med opskrifter osv til
Windows. Mac-brugere kan bare finde det samme på internettet i stedet for.

---

Frank E. N. Stein wrote:
> Erik Richard Sørensen skrev:
>>> Har lige haft en mindre diskussion (igen) med min søn ingeniøren.
>>> Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
>>> Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
>>> data,.....siger han. Så meget som jeg holder af ham, er det mig
>>> inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
>>> Er der nogen der har et par argumenter til næste gang vi mødes?
>>
>> Hvis han tænker på MS Access, så er det da noget af det værste gang
>> bras, der nogensinde er lavet.
>
> Access er glimrende til det det er lavet til.
>
>> Det er ustabilt, uhandy og fyldt med alvorlige fejl i selve basekernen.
>
> Det kan ikke være meget erfaring du har med det.

Helt ærlig, så må du hellere sige, at det er noget, du ikke ander en
hujende f... om!

>> Desuden er Access end ikke kompatibel med hverken Firefox, Camino,
>> SeaMonkey, Netscape eller Opera.
>
> Det er der heller ikke andre databaser der er. Webbrowsere taler med
> webservere, ikke databaser.

?? Nå, - det er da ellers noget, jeg jævnligt gør med min Seamonkey på
forskellige FMP baser. Du glemmer vist, at FMP kan bruges til at lave
lynhurtige websider/webbases med...

>> Den kan kun arbejde sammen med Explorer. Desuden er der uhyggelige
>> mangler i sådan noget som Unicode understøttelse.
>
> Access lagrer al data som unicode.

Ja, i et 'simuleret' Unicode 7 format, der ikke længere bruges af andre
end MS selv.

>> De 'plug-ins', som MS laver til andre baseprogrammer, lider af
>> manglende kompatibilitet og er meget langsomme i brug.
>>
>> Tager du derimod de andre rigtig store databaser - Filemaker Pro, 4th
>> Dimension og opensource baserne SQL og MySQL, så er der overhovedet
>> ingen forskel hverken i programmernes muligheder eller i
>> kompatibilitet - hverken på Mac eller Windows.
>
> Filemaker er ikke en rigtig stor database.

Ac quantus multos tenebrae est! - Det viser jo tydeligt, at du ikke véd,
hvad du snakker om. FMP overgås kun af SQL/MySQL i antallet af brugere...

>> Mine erfaringer er, at en velkonstrueret database i Filemaker sat op
>> mod en tilsvarende MSAccess, så er det helt klart Filemaker, der er
>> den hurtigste.
>
> Du må gerne prøve at bilde dig selv ind at du har set et gyldigt
> tetscenarie.

Det er ikke nogen 'tetscenarie', - hvad det så ellers betyder, - men
reelle facts hos nogle af mine tidligere faste kunder, som jeg har
serviceret gennem flere år

>> Selvfølgelig kommer det an på hele konstruktion og optimering, men
>> hvis vi har to 100% optimerede baser i Filemaker og Access, så vinder
>> Filemaker med flere hestelængder på en Mac mod en PC. Hvis man bruger
>> en 100% optimeret Filemaker base i både Mac og Win versionen på hver
>> sin maskine, er der overhovedet ingen forskel.
>>
>> En væsentlig ting, man (endnu) ikke kan i Access, er fx. at kunne søge
>> i en fuldstændig lukket FMP base fra et andet sted end dér, hvor FMP
>> basen er placeret.
>
> Hvordan får du det til en væsentlig ting?

Fordi der er nogle grupper blandt de offentlige myndigheder, der bruger
Access i bl.a. syndhedssystemet, mens der er fx. privatpraktiserende
læger, ingeniører m.fl., der bruger Filemaker. Det betyder så, at du
ikke på en anden fysisk adresse kan gå ind i din egen FMP base via
nettet og søge, finde og evt. hente specielle opl., som du ikke i
forvejen har udprintet.

Hvis det nu fx. var i sysgehussystemet, så ville sådanne manglende
muligheder i visse tilfælde kunne være af livsvigtig værdi. Jeg kender
faktisk til tilfælde, hvor en sekretær hos en af mine gamle kunder - en
privatpraktiserende specialist har måttet have udprintet data fra sin
egen base og sendt til et hospital med taxa, før han kunne gå videre i
et livstruende behandlingsforløb.

>> Filemaker laver en plugin til Access, der gør det muligt at kunne
>> importere og/eller læse data fra visse dele af en lukket FMP base på
>> en Access-baseret computer. Men MS vil ikke frigive de koder, der skal
>> til for at plugin'en kan blive 100% kompatibel med Access.
>
> Filemaker kan bare implementere ordentlig ODBC-understøttelse, så er den
> ged barberet.

Den ODBC, der er implementeret i FMP er klart bedre end det skidt, som
M$ leverer.

>> - Og så er det altså flintrende ligegyldigt, om FMP basen befinder sig
>> på en Mac eller en Wintel.
>>
>> Så min konklusion er, at der ingen forskel er overhovedet.
>
> Forskellen er at der er et hav af små databaser med opskrifter osv til
> Windows. Mac-brugere kan bare finde det samme på internettet i stedet for.

Øh? - hvad pokker har det med databasers hurtighed at gøre?

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rgds. Grüße, Mvh. Erik Richard Sørensen, Member of ADC
<mac-man_NOSP@M_stofanet.dk> <http://www.nisus.com>
NisusWriter - The Future In Multilingual Textprocessing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> FMP overgås kun af SQL/MySQL i antallet af brugere...

Opfatter du 'SQL' som en database?

Det er et forespørgselssprog, der er almindeligt brugt i
relationsdatabaser [og File Maker Pro er /ikke/ en ralationsdatabase].
--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne wrote:
> Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:
>> FMP overgås kun af SQL/MySQL i antallet af brugere...
>
> Opfatter du 'SQL' som en database?
>
> Det er et forespørgselssprog, der er almindeligt brugt i
> relationsdatabaser

du kan uden videre bygge komplette databaser med SQL som fx. i MySQL
basesystemerne...

> [og File Maker Pro er /ikke/ en ralationsdatabase].

Det da ved den søde grød, den er! Fra og med ver. 7.0 og op er FMP 100%
relationel. - Ta' et kig på den nye 9.0, du kan downloade som 30-dages
full-working demo. - Jeg har lige hentet den, men indtil nu kun afprøvet
den en ganske lille smule. - Den er suveræn!

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rgds. Grüße, Mvh. Erik Richard Sørensen, Member of ADC
<mac-man_NOSP@M_stofanet.dk> <http://www.nisus.com>
NisusWriter - The Future In Multilingual Textprocessing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:

> du kan uden videre bygge komplette databaser med SQL som fx. i MySQL
> basesystemerne...

Erik, kan du huske at jeg skrev noget om at andre måske blev
forvirrede over din brug af ordet database? Her har vi balladen :)

> > [og File Maker Pro er /ikke/ en ralationsdatabase].
>
> Det da ved den søde grød, den er! Fra og med ver. 7.0 og op er FMP
> 100% relationel. - Ta' et kig på den nye 9.0, du kan downloade som
> 30-dages full-working demo. - Jeg har lige hentet den, men indtil nu
> kun afprøvet den en ganske lille smule. - Den er suveræn!

Jeg kiggede men kan ikke finde en side hos filemaker.com hvor de
beskriver dens tekniske opbygning. Har du faldet over sådan en side
på et tidspunkt? Det vil jeg gerne se.

(Og et produkt kan sagtens være suverænt uden at være en relationel
database :)

--
Thorbjørn Ravn Andersen "... plus ... Tubular iMacs!"

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> (Og et produkt kan sagtens være suverænt uden at være en relationel
> database :)

Ja, og til små personlige databaser er FMP skam fremragende. Jeg ville
dog aldrig anvende det til regnskabssystemer - alene den manglende
transaktioner gør jo, at man ville risikere at debet og kredit ikke
ville balancere.

Jeg mangler dog en bedre søgefunktion, som gjorde at man ville fremfinde
søgestrenge /inden for den enkelte post/, som det er muligt i Access
[der til gengæld ikke understøtter bruge af forskellige skriftsnit i
samme felt]. Dermed bliver FMP dårligere til at lave notat-databaser.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne wrote:
> Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
>> (Og et produkt kan sagtens være suverænt uden at være en relationel
>> database :)
>
> Ja, og til små personlige databaser er FMP skam fremragende. Jeg ville
> dog aldrig anvende det til regnskabssystemer - alene den manglende
> transaktioner gør jo, at man ville risikere at debet og kredit ikke
> ville balancere.

Jeg vil ikke just kalde en base på knap 2gb for en 'lille personlig
database'...

Og jeg kan da tilføje, at FMP sagtens kan bruges som
regnskabs-/bogholderistyring. Det har jeg fx. selv brugt i de år, jeg
havde forretning, og der har altid været overensstemmelse mellem både
kredit og debit...

> Jeg mangler dog en bedre søgefunktion, som gjorde at man ville fremfinde
> søgestrenge /inden for den enkelte post/, som det er muligt i Access
> [der til gengæld ikke understøtter bruge af forskellige skriftsnit i
> samme felt]. Dermed bliver FMP dårligere til at lave notat-databaser.

Det er ikke korrekt. FMP kan bruge forskellige både skrifttyper og
skriftsnit i samme felt, og man kan definere søgesystemerne, så der kun
søges på fx. kursiv skrift indrammet af både alm. citationstegn og curly
citationstegn. Jeg har set det i praktisk brug hos en tidl. kunde. - Men
hvordan det skal defineres, kan jeg ikke huske...

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rgds. Grüße, Mvh. Erik Richard Sørensen, Member of ADC
<mac-man_NOSP@M_stofanet.dk> <http://www.nisus.com>
NisusWriter - The Future In Multilingual Textprocessing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:

> > dog aldrig anvende det til regnskabssystemer - alene den manglende
> > transaktioner gør jo, at man ville risikere at debet og kredit ikke
> > ville balancere.
>
> Jeg vil ikke just kalde en base på knap 2gb for en 'lille personlig
> database'...

Erik, de "transaktioner" som Per snakker om, giver mulighed for at
flere individuelle operationer kan betragtes som en enkelt, som enten
lykkes eller ikke lykkes.

Det kan fx være den logiske operation "opdater regnskab" som kan bestå
af de to individuelle operationer: "indsæt række i kredittabel" og
"indsæt række i debitortabel". I fx et filsystem vil disse to
handlinger være separate (kopier fil A og kopier fil B) men i en
database er det vigtigt at kunne markere at de logisk set er een
atomar operation.

Det bruger man sædvanligvis "commit" og "rollback" til. Hvis både
operation 1 og operation 2 lykkedes fortæller man databasen at NU er
man tilfreds med en "commit", men hvis de fejler bruger man "rollback"
til at rulle tilbage til start. Det er samme teknik som journalling
filsystemer bruger til at lave hurtige opstartscheck hvis maskinen er
hevet uregelmæssigt ned.

Mængden af data der proppes ind og svartider er bedøvende ligegyldigt
her, det er hvordan databasen håndterer fejlsituationer der er
vigtigt.

--
Thorbjørn Ravn Andersen "... plus ... Tubular iMacs!"

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> Per Rønne wrote:
> > Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
> >> (Og et produkt kan sagtens være suverænt uden at være en relationel
> >> database :)
> >
> > Ja, og til små personlige databaser er FMP skam fremragende. Jeg ville
> > dog aldrig anvende det til regnskabssystemer - alene den manglende
> > transaktioner gør jo, at man ville risikere at debet og kredit ikke
> > ville balancere.
>
> Jeg vil ikke just kalde en base på knap 2gb for en 'lille personlig
> database'...
>
> Og jeg kan da tilføje, at FMP sagtens kan bruges som
> regnskabs-/bogholderistyring. Det har jeg fx. selv brugt i de år, jeg
> havde forretning, og der har altid været overensstemmelse mellem både
> kredit og debit...

FileMaker understøtter ikke transaktioner ...

<http://en.wikipedia.org/wiki/Database_transaction>

> > Jeg mangler dog en bedre søgefunktion, som gjorde at man ville fremfinde
> > søgestrenge /inden for den enkelte post/, som det er muligt i Access
> > [der til gengæld ikke understøtter bruge af forskellige skriftsnit i
> > samme felt]. Dermed bliver FMP dårligere til at lave notat-databaser.
>
> Det er ikke korrekt. FMP kan bruge forskellige både skrifttyper og
> skriftsnit i samme felt, og man kan definere søgesystemerne, så der kun
> søges på fx. kursiv skrift indrammet af både alm. citationstegn og curly
> citationstegn. Jeg har set det i praktisk brug hos en tidl. kunde. - Men
> hvordan det skal defineres, kan jeg ikke huske...

Og det var heller ikke det jeg fandt mangelfuldt.

FMP understøtter forskellige fonte mv i samme felt. Men det gør Access
ikke.

Til gengæld vil en søgning på en tekstreng i Access gå fra forekomst til
forekomst også inden for et felt. Den facilitet mangler i FMP.
Betydning? FMP er ikke god til at bruge som note-database, når man har
brug for at søge på tekstrenge i noterne.

Noter? Som når man tager notitser til et møde, eller af en undervisning
man deltager i.


--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne wrote:
> Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:
>> Per Rønne wrote:
>>> Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
>>>> (Og et produkt kan sagtens være suverænt uden at være en relationel
>>>> database :)
>>> Ja, og til små personlige databaser er FMP skam fremragende. Jeg ville
>>> dog aldrig anvende det til regnskabssystemer - alene den manglende
>>> transaktioner gør jo, at man ville risikere at debet og kredit ikke
>>> ville balancere.
>> Jeg vil ikke just kalde en base på knap 2gb for en 'lille personlig
>> database'...
>>
>> Og jeg kan da tilføje, at FMP sagtens kan bruges som
>> regnskabs-/bogholderistyring. Det har jeg fx. selv brugt i de år, jeg
>> havde forretning, og der har altid været overensstemmelse mellem både
>> kredit og debit...
>
> FileMaker understøtter ikke transaktioner ...
>
> <http://en.wikipedia.org/wiki/Database_transaction>

Undskyld mig, men jeg er ved at være noget så fandens træt af, at der
hele tiden og så igen henvises til Wikipedia og den såkaldte
fortræffeligheder. Jeg synes, det snart er på tide, at folk tager og
lytter efter og selv undersøger, hvad 'sagen'' drejer sig om!

Så sent som i sidste uge var der en del både skriverier og snak i div.
radio- og TV udsendelser om, hvor fejlbehæftet Wikipedia er, og ligefrem
hvordan folk er gået ind og rettet ellers nogenlunde pålidelige artikler
til, så de er totalt forværnget i forhold til sandheden - den faktuelle
sandhed!

Læs lige instruktionsvejledningen til de nyewte versioner af Filemaker
8.0, 8.5 og 9.0 - både den almindelige og Filemaker Advanced!

>>> Jeg mangler dog en bedre søgefunktion, som gjorde at man ville fremfinde
>>> søgestrenge /inden for den enkelte post/, som det er muligt i Access
>>> [der til gengæld ikke understøtter bruge af forskellige skriftsnit i
>>> samme felt]. Dermed bliver FMP dårligere til at lave notat-databaser.
>> Det er ikke korrekt. FMP kan bruge forskellige både skrifttyper og
>> skriftsnit i samme felt, og man kan definere søgesystemerne, så der kun
>> søges på fx. kursiv skrift indrammet af både alm. citationstegn og curly
>> citationstegn. Jeg har set det i praktisk brug hos en tidl. kunde. - Men
>> hvordan det skal defineres, kan jeg ikke huske...
>
> Og det var heller ikke det jeg fandt mangelfuldt.
>
> FMP understøtter forskellige fonte mv i samme felt. Men det gør Access
> ikke.

OK, så er vi enige, men din måde at formulere det på, kunne meget let
forstås modsat.

> Til gengæld vil en søgning på en tekstreng i Access gå fra forekomst til
> forekomst også inden for et felt. Den facilitet mangler i FMP.

Det kan jeg godt garantere for, at den kan. Det kommer fuldstændig an
på, hvordan du definerer dine relationer i forhold til det enkelte felts
søgeevne.

> Betydning? FMP er ikke god til at bruge som note-database, når man har
> brug for at søge på tekstrenge i noterne.
>
> Noter? Som når man tager notitser til et møde, eller af en undervisning
> man deltager i.

Jo, det kommer igen an på, hvordan du definerer dine søgefunktioner.

Nu vil jeg ikke sidde og udlevere, hvad især en af mine tidl. kunder
brugte sin FMP base til, men jeg kan garantere for, at hvis der i et
såkaldt ''indgangskort' blev tastet div. data ind, kunne man i hele
basen få frem, præcist, hvor disse data forekom, hvornår de var
indtastet og i hvilken forbindelse og sammenhæng, de var indtastet

Desværre har jeg ikke holdt min FMP viden uptodate, så jeg kan ikke give
dig - eller andre - de eksakte indtastningsstrenge og
funktionsrelationer.

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rgds. Grüße, Mvh. Erik Richard Sørensen, Member of ADC
<mac-man_NOSP@M_stofanet.dk> <http://www.nisus.com>
NisusWriter - The Future In Multilingual Textprocessing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> Per Rønne wrote:
> > Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:
> >> Per Rønne wrote:
> >>> Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
> >>>> (Og et produkt kan sagtens være suverænt uden at være en relationel
> >>>> database :)
> >>> Ja, og til små personlige databaser er FMP skam fremragende. Jeg ville
> >>> dog aldrig anvende det til regnskabssystemer - alene den manglende
> >>> transaktioner gør jo, at man ville risikere at debet og kredit ikke
> >>> ville balancere.
> >> Jeg vil ikke just kalde en base på knap 2gb for en 'lille personlig
> >> database'...
> >>
> >> Og jeg kan da tilføje, at FMP sagtens kan bruges som
> >> regnskabs-/bogholderistyring. Det har jeg fx. selv brugt i de år, jeg
> >> havde forretning, og der har altid været overensstemmelse mellem både
> >> kredit og debit...
> >
> > FileMaker understøtter ikke transaktioner ...
> >
> > <http://en.wikipedia.org/wiki/Database_transaction>
>
> Undskyld mig, men jeg er ved at være noget så fandens træt af, at der
> hele tiden og så igen henvises til Wikipedia og den såkaldte
> fortræffeligheder. Jeg synes, det snart er på tide, at folk tager og
> lytter efter og selv undersøger, hvad 'sagen'' drejer sig om!

Jeg har læst hvad wikipedia skriver om transaktioner, og da jeg udmærket
ved hvad transaktioner er for noget, kan jeg kun konstatere, at det der
står er korrekt. Det er ganske simpelt lettere at henvise til wikipedia,
end selv at skrive det hele igen.

> Så sent som i sidste uge var der en del både skriverier og snak i div.
> radio- og TV udsendelser om, hvor fejlbehæftet Wikipedia er, og ligefrem
> hvordan folk er gået ind og rettet ellers nogenlunde pålidelige artikler
> til, så de er totalt forværnget i forhold til sandheden - den faktuelle
> sandhed!

Det drejer sig jo om visse 'politiske' artikler - der er i øvrigt også
artikler der er 'beskyttede', og hvor man ikke bare kan ændre dem.

> Læs lige instruktionsvejledningen til de nyewte versioner af Filemaker
> 8.0, 8.5 og 9.0 - både den almindelige og Filemaker Advanced!

FileMaker har stadig ikke implementeret transaktionsbegrebet, som netop
er noget der gør at en række operationer på en database kædes sammen i
en 'atomar' operation, der enten i sin helhed lykkes eller ikke lykkes
når man sender en 'commit' ordre [man kan også sende en 'rollback'
ordre, som gør at hele transaktionen droppes].

Det er det der gør at databasens integritet opretholdes, hvilket er helt
centralt i eksempelvis regnskabssystemer. Databasen må ganske simpelt
ikke blive inkonsistent.

I øvrigt redegør Thorbjørn Ravn Andersen, der jo også er datalog,
udmærket for det.

> >>> Jeg mangler dog en bedre søgefunktion, som gjorde at man ville fremfinde
> >>> søgestrenge /inden for den enkelte post/, som det er muligt i Access
> >>> [der til gengæld ikke understøtter bruge af forskellige skriftsnit i
> >>> samme felt]. Dermed bliver FMP dårligere til at lave notat-databaser.
> >> Det er ikke korrekt. FMP kan bruge forskellige både skrifttyper og
> >> skriftsnit i samme felt, og man kan definere søgesystemerne, så der kun
> >> søges på fx. kursiv skrift indrammet af både alm. citationstegn og curly
> >> citationstegn. Jeg har set det i praktisk brug hos en tidl. kunde. - Men
> >> hvordan det skal defineres, kan jeg ikke huske...
> >
> > Og det var heller ikke det jeg fandt mangelfuldt.
> >
> > FMP understøtter forskellige fonte mv i samme felt. Men det gør Access
> > ikke.
>
> OK, så er vi enige, men din måde at formulere det på, kunne meget let
> forstås modsat.
>
> > Til gengæld vil en søgning på en tekstreng i Access gå fra forekomst til
> > forekomst også inden for et felt. Den facilitet mangler i FMP.

Tjae, du misforstod i hvert fald.

> Det kan jeg godt garantere for, at den kan. Det kommer fuldstændig an
> på, hvordan du definerer dine relationer i forhold til det enkelte felts
> søgeevne.
>
> > Betydning? FMP er ikke god til at bruge som note-database, når man har
> > brug for at søge på tekstrenge i noterne.
> >
> > Noter? Som når man tager notitser til et møde, eller af en undervisning
> > man deltager i.
>
> Jo, det kommer igen an på, hvordan du definerer dine søgefunktioner.
>
> Nu vil jeg ikke sidde og udlevere, hvad især en af mine tidl. kunder
> brugte sin FMP base til, men jeg kan garantere for, at hvis der i et
> såkaldt ''indgangskort' blev tastet div. data ind, kunne man i hele
> basen få frem, præcist, hvor disse data forekom, hvornår de var
> indtastet og i hvilken forbindelse og sammenhæng, de var indtastet
>
> Desværre har jeg ikke holdt min FMP viden uptodate, så jeg kan ikke give
> dig - eller andre - de eksakte indtastningsstrenge og
> funktionsrelationer.

Ja, jeg kan i hvert fald ikke se funktionaliteten i FMP 7, som jeg har.
Her går man jo bare ind i 'Find Mode' når man skal finde tingene, og så
søger man på det enkelte felt, evt på 'beregnede' felter med streng
concatenation.

Når jeg søger i en Access database så finder jeg den første post der
indeholder en streng, og strengen markeres. Søger jeg igen, og er der
flere forekomster af strengen i samme post, markeres den næste
forekomst; ellers gås videre til næste post med strengen. Og så
fremdeles.

Det er noget der gør, at man kan have et felt i en database, hvor man
skriver noter eller referater, der kan være temmelig lange, og alligevel
let søgbare.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> Per Rønne wrote:
> > Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:
> >> FMP overgås kun af SQL/MySQL i antallet af brugere...
> >
> > Opfatter du 'SQL' som en database?
> >
> > Det er et forespørgselssprog, der er almindeligt brugt i
> > relationsdatabaser
>
> du kan uden videre bygge komplette databaser med SQL som fx. i MySQL
> basesystemerne...

Ja, med kommandoer som 'create table' kan nye relationer defineres. Men
SQL er altså grundlæggende et forespørgselssprog med visse udvidelser,
og det er ikke i sig selv en database.

> > [og File Maker Pro er /ikke/ en ralationsdatabase].
>
> Det da ved den søde grød, den er! Fra og med ver. 7.0 og op er FMP 100%
> relationel. - Ta' et kig på den nye 9.0, du kan downloade som 30-dages
> full-working demo. - Jeg har lige hentet den, men indtil nu kun afprøvet
> den en ganske lille smule. - Den er suveræn!

Det kan så kun skyldes at du ikke ved hvad en relationsdatabase er for
noget. Og så kun meget kort noget, som i hvert fald ikke opfyldes af
FileMaker:

En relation [hyppigt kaldet en 'tabel'] er en mægde af tupler [poster
eller rækker]. En mængde kan ikke indeholde dubletter, lige som der ikke
kan forekomme en rækkefølge.

Men jeg nøjes med følgende link:

<http://en.wikipedia.org/wiki/Database#Relational_model>

PS. På min Mac bruger jeg selv FileMaker Pro. Men selv om de selv kalder
den relationel, er den det altså ikke - i hvert fald ikke for en
datalog.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne <per@RQNNE.invalid> wrote:

> En relation [hyppigt kaldet en 'tabel'] er en mægde af tupler [poster
> eller rækker]. En mængde kan ikke indeholde dubletter, lige som der ikke
> kan forekomme en rækkefølge.

Med den definition er MySQL heller ikke en relationsdatabase. Det er der
faktisk ikke ret mange databaser, som er.

--
Thorkil Olesen,
Hanstholm.

---

Thorkil Olesen <slet.dette.thorkil.og.dette@pip.dknet.dk> wrote:

> Per Rønne <per@RQNNE.invalid> wrote:
>
> > En relation [hyppigt kaldet en 'tabel'] er en mægde af tupler [poster
> > eller rækker]. En mængde kan ikke indeholde dubletter, lige som der ikke
> > kan forekomme en rækkefølge.
>
> Med den definition er MySQL heller ikke en relationsdatabase. Det er der
> faktisk ikke ret mange databaser, som er.

Korrekt, og derfor skal man altid sørge for at en tabel ['relation'] i
erklæringen får tilføjet en betingelse om en /primary key/.

Ingen tabelerklæring uden er primærnøgleerklæring ...
--
Per Erik Rønne
http://www.RQNNE.dk

---

Erik Richard Sørensen skrev:

>>>> Har lige haft en mindre diskussion (igen) med min søn ingeniøren.
>>>> Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
>>>> Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
>>>> data,.....siger han. Så meget som jeg holder af ham, er det mig
>>>> inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
>>>> Er der nogen der har et par argumenter til næste gang vi mødes?
>>>
>>> Hvis han tænker på MS Access, så er det da noget af det værste gang
>>> bras, der nogensinde er lavet.
>>
>> Access er glimrende til det det er lavet til.
>>
>>> Det er ustabilt, uhandy og fyldt med alvorlige fejl i selve basekernen.
>>
>> Det kan ikke være meget erfaring du har med det.
>
> Helt ærlig, så må du hellere sige, at det er noget, du ikke ander en
> hujende f... om!

Jeg aner en del om både Access og Filemaker. Jeg aner intet om hvad din
erfaring er, men udtaler mig blot om hvad dine påstande tyder på.

>>> Desuden er Access end ikke kompatibel med hverken Firefox, Camino,
>>> SeaMonkey, Netscape eller Opera.
>>
>> Det er der heller ikke andre databaser der er. Webbrowsere taler med
>> webservere, ikke databaser.
>
> ?? Nå, - det er da ellers noget, jeg jævnligt gør med min Seamonkey på
> forskellige FMP baser.

Nej, det gør du ikke.

> Du glemmer vist, at FMP kan bruges til at lave
> lynhurtige websider/webbases med...

Filemaker har en indbygget webserver.

>>> Den kan kun arbejde sammen med Explorer. Desuden er der uhyggelige
>>> mangler i sådan noget som Unicode understøttelse.
>>
>> Access lagrer al data som unicode.
>
> Ja, i et 'simuleret' Unicode 7 format, der ikke længere bruges af andre
> end MS selv.

"Microsoft Office er baseret på tekstkodningsstandarden Unicode, som gør
det muligt at vise dokumenter korrekt i Office-programmer, uanset
hvilket sprog de er skrevet i, forudsat at operativsystemet understøtter
de specifikke tegn på det pågældende sprog."

>>> De 'plug-ins', som MS laver til andre baseprogrammer, lider af
>>> manglende kompatibilitet og er meget langsomme i brug.
>>>
>>> Tager du derimod de andre rigtig store databaser - Filemaker Pro, 4th
>>> Dimension og opensource baserne SQL og MySQL, så er der overhovedet
>>> ingen forskel hverken i programmernes muligheder eller i
>>> kompatibilitet - hverken på Mac eller Windows.
>>
>> Filemaker er ikke en rigtig stor database.
>
> Ac quantus multos tenebrae est! - Det viser jo tydeligt, at du ikke véd,
> hvad du snakker om. FMP overgås kun af SQL/MySQL i antallet af brugere...

Så Filemaker er større end Oracle?
Er der en chance for at du kan afsløre din kilde?

>>> Mine erfaringer er, at en velkonstrueret database i Filemaker sat op
>>> mod en tilsvarende MSAccess, så er det helt klart Filemaker, der er
>>> den hurtigste.
>>
>> Du må gerne prøve at bilde dig selv ind at du har set et gyldigt
>> tetscenarie.
>
> Det er ikke nogen 'tetscenarie', - hvad det så ellers betyder,

Det betyder du har et gyldigt sammenligningsgrundlag der er til at stole på.

> - men
> reelle facts hos nogle af mine tidligere faste kunder, som jeg har
> serviceret gennem flere år

Dine kunder har ikke haft to ens databaser baseret på hhv Access og
Filemaker.

>>> Selvfølgelig kommer det an på hele konstruktion og optimering, men
>>> hvis vi har to 100% optimerede baser i Filemaker og Access, så vinder
>>> Filemaker med flere hestelængder på en Mac mod en PC. Hvis man bruger
>>> en 100% optimeret Filemaker base i både Mac og Win versionen på hver
>>> sin maskine, er der overhovedet ingen forskel.
>>>
>>> En væsentlig ting, man (endnu) ikke kan i Access, er fx. at kunne
>>> søge i en fuldstændig lukket FMP base fra et andet sted end dér, hvor
>>> FMP basen er placeret.
>>
>> Hvordan får du det til en væsentlig ting?
>
> Fordi der er nogle grupper blandt de offentlige myndigheder, der bruger
> Access i bl.a. syndhedssystemet, mens der er fx. privatpraktiserende
> læger, ingeniører m.fl., der bruger Filemaker. Det betyder så, at du
> ikke på en anden fysisk adresse kan gå ind i din egen FMP base via
> nettet og søge, finde og evt. hente specielle opl., som du ikke i
> forvejen har udprintet.

Hvis basen er fuldstændigt lukket, bør det være en push-operation.
Dit kritikpunkt svarer til at du brokker dig over at du har svært ved at
høre hvad folk siger efter du har kneblet dem.

> Hvis det nu fx. var i sysgehussystemet, så ville sådanne manglende
> muligheder i visse tilfælde kunne være af livsvigtig værdi. Jeg kender
> faktisk til tilfælde, hvor en sekretær hos en af mine gamle kunder - en
> privatpraktiserende specialist har måttet have udprintet data fra sin
> egen base og sendt til et hospital med taxa, før han kunne gå videre i
> et livstruende behandlingsforløb.

En skam de ikke havde opdaget det ultramoderne maskineri kaldet en
"fax". Tænk hvor mange liv de så kunne have reddet i tidens løb.

>>> Filemaker laver en plugin til Access, der gør det muligt at kunne
>>> importere og/eller læse data fra visse dele af en lukket FMP base på
>>> en Access-baseret computer. Men MS vil ikke frigive de koder, der
>>> skal til for at plugin'en kan blive 100% kompatibel med Access.
>>
>> Filemaker kan bare implementere ordentlig ODBC-understøttelse, så er
>> den ged barberet.
>
> Den ODBC, der er implementeret i FMP er klart bedre end det skidt, som
> M$ leverer.

Det bliver du nødt til at uddybe. Filemakers implementering af ODBC
viser tydelige tegn på at det ikke er den metode de forventer kunderne
benytter sig af.

>>> - Og så er det altså flintrende ligegyldigt, om FMP basen befinder
>>> sig på en Mac eller en Wintel.
>>>
>>> Så min konklusion er, at der ingen forskel er overhovedet.
>>
>> Forskellen er at der er et hav af små databaser med opskrifter osv til
>> Windows. Mac-brugere kan bare finde det samme på internettet i stedet
>> for.
>
> Øh? - hvad pokker har det med databasers hurtighed at gøre?

Der blev ikke påstået bedre hastighed, men bare "bedre".

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> Erling Hansen wrote:
> > Har lige haft en mindre diskussion (igen) med min søn ingeniøren.
> > Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
> > Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
> > data,.....siger han. Så meget som jeg holder af ham, er det mig
> > inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
> > Er der nogen der har et par argumenter til næste gang vi mødes?
>
> Hvis han tænker på MS Access, så er det da noget af det værste gang
> bras, der nogensinde er lavet. Det er ustabilt, uhandy og fyldt med
> alvorlige fejl i selve basekernen. Desuden er Access end ikke kompatibel
> med hverken Firefox, Camino, SeaMonkey, Netscape eller Opera. Den kan
> kun arbejde sammen med Explorer. Desuden er der uhyggelige mangler i
> sådan noget som Unicode understøttelse. De 'plug-ins', som MS laver til
> andre baseprogrammer, lider af manglende kompatibilitet og er meget
> langsomme i brug.
>
> Tager du derimod de andre rigtig store databaser - Filemaker Pro, 4th
> Dimension og opensource baserne SQL og MySQL, så er der overhovedet
> ingen forskel hverken i programmernes muligheder eller i kompatibilitet
> - hverken på Mac eller Windows.
>
> Mine erfaringer er, at en velkonstrueret database i Filemaker sat op mod
> en tilsvarende MSAccess, så er det helt klart Filemaker, der er den
> hurtigste.
>
> Selvfølgelig kommer det an på hele konstruktion og optimering, men hvis
> vi har to 100% optimerede baser i Filemaker og Access, så vinder
> Filemaker med flere hestelængder på en Mac mod en PC. Hvis man bruger en
> 100% optimeret Filemaker base i både Mac og Win versionen på hver sin
> maskine, er der overhovedet ingen forskel.
>
> En væsentlig ting, man (endnu) ikke kan i Access, er fx. at kunne søge i
> en fuldstændig lukket FMP base fra et andet sted end dér, hvor FMP basen
> er placeret. Filemaker laver en plugin til Access, der gør det muligt at
> kunne importere og/eller læse data fra visse dele af en lukket FMP base
> på en Access-baseret computer. Men MS vil ikke frigive de koder, der
> skal til for at plugin'en kan blive 100% kompatibel med Access. - Og så
> er det altså flintrende ligegyldigt, om FMP basen befinder sig på en Mac
> eller en Wintel.
>
> Så min konklusion er, at der ingen forskel er overhovedet.
>
> mvh. Erik Richard
Tak for en redegørelse jeg virkelig kan bruge til noget. Jeg tror jeg
kopierer den og mailer den til sønnen.
mvh
Erling

---

Erling Hansen <eh-dh@mail.dk> wrote:
> Erik Richard Sørensen <NOSPAM@NOSPAM.dk> wrote:

> > Erling Hansen wrote:
> > > Har lige haft en mindre diskussion (igen) med min søn ingeniøren.
> > > Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
> > > Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
> > > data,.....siger han. Så meget som jeg holder af ham, er det mig
> > > inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
> > > Er der nogen der har et par argumenter til næste gang vi mødes?
> >
> > Hvis han tænker på MS Access, så er det da noget af det værste gang
> > bras, der nogensinde er lavet. Det er ustabilt, uhandy og fyldt med
> > alvorlige fejl i selve basekernen. Desuden er Access end ikke kompatibel
> > med hverken Firefox, Camino, SeaMonkey, Netscape eller Opera. Den kan
> > kun arbejde sammen med Explorer. Desuden er der uhyggelige mangler i
> > sådan noget som Unicode understøttelse. De 'plug-ins', som MS laver til
> > andre baseprogrammer, lider af manglende kompatibilitet og er meget
> > langsomme i brug.
> >
> > Tager du derimod de andre rigtig store databaser - Filemaker Pro, 4th
> > Dimension og opensource baserne SQL og MySQL, så er der overhovedet
> > ingen forskel hverken i programmernes muligheder eller i kompatibilitet
> > - hverken på Mac eller Windows.
> >
> > Mine erfaringer er, at en velkonstrueret database i Filemaker sat op mod
> > en tilsvarende MSAccess, så er det helt klart Filemaker, der er den
> > hurtigste.
> >
> > Selvfølgelig kommer det an på hele konstruktion og optimering, men hvis
> > vi har to 100% optimerede baser i Filemaker og Access, så vinder
> > Filemaker med flere hestelængder på en Mac mod en PC. Hvis man bruger en
> > 100% optimeret Filemaker base i både Mac og Win versionen på hver sin
> > maskine, er der overhovedet ingen forskel.
> >
> > En væsentlig ting, man (endnu) ikke kan i Access, er fx. at kunne søge i
> > en fuldstændig lukket FMP base fra et andet sted end dér, hvor FMP basen
> > er placeret. Filemaker laver en plugin til Access, der gør det muligt at
> > kunne importere og/eller læse data fra visse dele af en lukket FMP base
> > på en Access-baseret computer. Men MS vil ikke frigive de koder, der
> > skal til for at plugin'en kan blive 100% kompatibel med Access. - Og så
> > er det altså flintrende ligegyldigt, om FMP basen befinder sig på en Mac
> > eller en Wintel.
> >
> > Så min konklusion er, at der ingen forskel er overhovedet.
> >
> > mvh. Erik Richard
> Tak for en redegørelse jeg virkelig kan bruge til noget. Jeg tror jeg
> kopierer den og mailer den til sønnen.

Det vil være synd.
Send istedet Martin Schultz's redegørelse, da det er det eneste indlæg
der tilnærmelsesvis giver dig svar på dine spørgsmål. Jeg vil gerne
give dig mit syn på sagen, det kan muligligvis besvare dine spørgsmål:

Der skrives flere små databaser i Access (som kun køre på windows),
hvorfor udbudet af databaser er størst på windows.

Din søns udsagn har intet at gøre med hvad der er bedst, men er
udelukkende et spørgsmål om antallet af små privat skrevne databaser
med tilhørende runtimes. Såfremt det større udbud er lig med "bedst"
har han ret. Set fra en forbrugers synspunkt vil jeg give ham ret i
hans definition af "bedst"..

Tråden har udviklet sig til en en tråd ikke giver svar på dit
spørgsmål - årsagen er Eriks indlæg som mildt sagt er noget værre vås.
Således udvikler Eriks inlæg sig ofte - og med god grund.

--
Morten Reippuert Knudsen <http://blog.reippuert.dk>

Merlin Works CR-3/2.5 & Campagnolo Chorus 2007.

---

Erling Hansen <eh-dh@mail.dk> wrote:

> Har lige haft en mindre diskussion (igen) med min søn ingeniøren.
> Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
> Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
> data,.....siger han. Så meget som jeg holder af ham, er det mig
> inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
> Er der nogen der har et par argumenter til næste gang vi mødes?

Man skal da her ikke se på OS, men på databaseprogrammer, og om man
kører Oracle (som er den mest brugte database) under Windows Server,
MacOS X Server eller en anden afart af UNIX, er vel så mindre
væsentligt. Som regel kører Oracle serveren dog på en UNIX-maskine, og
her er det så i Windows-miljøer ikke ualmindeligt, at man bruger Access
som klient - så HKerne tror at de befinder sig i et rent Microsoft
miljø.

--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> kører Oracle (som er den mest brugte database) under Windows Server,

Er det det? Hvem siger det?

Bortset fra det skulle du iøvrigt engang lære den Power-baserede
iSeries/System i/AS400 platform at kende. DB2 er indbygget i selve
operativsystemet og gør mange ting meget, meget nemt.

--
Thorbjørn Ravn Andersen "... plus ... Tubular iMacs!"

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > kører Oracle (som er den mest brugte database) under Windows Server,
>
> Er det det? Hvem siger det?

Det har jeg altså altid hørt, og det har også hele tiden været min
erfaring (men som nævnt som regel på en UNIX Server).

> Bortset fra det skulle du iøvrigt engang lære den Power-baserede
> iSeries/System i/AS400 platform at kende. DB2 er indbygget i selve
> operativsystemet og gør mange ting meget, meget nemt.

En af mine brødre har et firma, der excellerer i AS 400. Her er han 'IBM
Partner', eller hvad detr nu hedder.

Så systemet er ikke helt ukendt for mig.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Erling Hansen <eh-dh@mail.dk> wrote:

> Har lige haft en mindre diskussion (igen) med min søn ingeniøren.
> Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
> Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
> data,.....siger han. Så meget som jeg holder af ham, er det mig
> inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
> Er der nogen der har et par argumenter til næste gang vi mødes?
> mvh
> Erling


Et eksempel er FileMaker, som kan bruges på både Mac og PC.

--
med venlig hilsen Jesper Haaber Gylling
http://www.gylling.net/
AIM/iChat: macnerd1965 + MSN: jesper@gylling.net
Skype: jesperhaabergylling

---

Erling Hansen <eh-dh@mail.dk> skrev 2007-09-08:
> Har lige haft en mindre diskussion (igen) med min søn ingeniøren.
> Han hævder hårdnakket, at windows databaseprogrammer er meget bedre end
> Macs, bl.a. når der skal søges efter opskrifter, ingredienser, tekniske
> data,.....siger han. Så meget som jeg holder af ham, er det mig
> inderligt imod at indrømme at nogen computer skulle være bedre end Mac.
> Er der nogen der har et par argumenter til næste gang vi mødes?

Nu er der skrevet en masse frem og tilbage i tråden, men IMHO er
spørgsmålet så løst formuleret at det ikke umiddelbart kan besvares.

Hvis vi taler om små personlige databaser med som folk laver til sig
selv er det ikke til og sige om mac eller win er bedst. Der er blot
personlige holdninger til hvilket program man bedst kan lide og lave dem
i. Der er intet teknisk der gør nogen forskel.

Taler vi om store "rigtige" database systemer (oracle, DB/2 osv) kommer
det meget an på hvad man skal bruge den til, hvilket system den kan
kører på og hvad en leverendør vil understøtte.

Martin
--
Besøg http://poltek.blogspot.com hvor jeg skriver om politiske
og tekniske nyheder!
Alt jeg skriver på usenet er mine egne personlige meninger
med mindre andet er angivet.

---

Martin Schultz <news2005@adsltips.invalid> writes:

> Taler vi om store "rigtige" database systemer (oracle, DB/2 osv) kommer
> det meget an på hvad man skal bruge den til, hvilket system den kan
> kører på og hvad en leverendør vil understøtte.

Det skal lige siges at jeg så på et tidspunkt at der var nogen der
lavede performance målinger på OS X versus Linux og nåede frem til at
der var "et eller andet" i OS X der sløvede. Jeg kan ikke huske hvad,
men fandt følgende artikel som argumenterer for at visse ting i OS X
skal ske en af gangen, og altså ikke afvikles samtidig. Det er ikke
godt for ydelsen hvis der er flere CPU'er i.

http://www.drunkenblog.com/drunkenblog-archives/000385.html

Det var dog ikke det jeg så dengang, men det er da tankevækkende :)
--
Thorbjørn Ravn Andersen "... plus ... Tubular iMacs!"

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> Martin Schultz <news2005@adsltips.invalid> writes:
>
> > Taler vi om store "rigtige" database systemer (oracle, DB/2 osv) kommer
> > det meget an på hvad man skal bruge den til, hvilket system den kan
> > kører på og hvad en leverendør vil understøtte.
>
> Det skal lige siges at jeg så på et tidspunkt at der var nogen der
> lavede performance målinger på OS X versus Linux og nåede frem til at
> der var "et eller andet" i OS X der sløvede. Jeg kan ikke huske hvad,
> men fandt følgende artikel som argumenterer for at visse ting i OS X
> skal ske en af gangen, og altså ikke afvikles samtidig. Det er ikke
> godt for ydelsen hvis der er flere CPU'er i.
>
> http://www.drunkenblog.com/drunkenblog-archives/000385.html
>
> Det var dog ikke det jeg så dengang, men det er da tankevækkende :)

Er det bevidst at du skriver MacOS X og ikke MacOS X Server?
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> Er det bevidst at du skriver MacOS X og ikke MacOS X Server?

Det er hip som hap i denne sammenhæng.
--
Thorbjørn Ravn Andersen "... plus ... Tubular iMacs!"

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > Er det bevidst at du skriver MacOS X og ikke MacOS X Server?
>
> Det er hip som hap i denne sammenhæng.

OK, jeg har ingen erfaring med MacOS X Server, og ved kun at
serverversionen ville gøre det muligt for mig at køre Oracle. Ikke at
jeg ville ofte 4000 kroner på det ...
--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne <per@rqnne.invalid> wrote:
> Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> > per@RQNNE.invalid (Per Rønne) writes:
> >
> > > Er det bevidst at du skriver MacOS X og ikke MacOS X Server?
> >
> > Det er hip som hap i denne sammenhæng.

> OK, jeg har ingen erfaring med MacOS X Server, og ved kun at
> serverversionen ville gøre det muligt for mig at køre Oracle. Ikke at
> jeg ville ofte 4000 kroner på det ...

Det er blot et spøgsmål om nogen en række services som findes i Mac
OS X Server og ikke Mac OS X klient - samt et installerscript der
tjekke om hvorvidt der er tale om en server eller klient installation.

Kernen er den samme

--
Morten Reippuert Knudsen <http://blog.reippuert.dk>

Merlin Works CR-3/2.5 & Campagnolo Chorus 2007.

---

per@RQNNE.invalid (Per Rønne) writes:

> OK, jeg har ingen erfaring med MacOS X Server, og ved kun at
> serverversionen ville gøre det muligt for mig at køre Oracle. Ikke at
> jeg ville ofte 4000 kroner på det ...

Prøvede du overhovedet at installere Oracle på en non-server OS X?

At Oracle supporterer OS X Server men ikke OS X betyder bare at hvis
du har problemer under OS X er Oracle ligeglad, men hvis du har
problemer under OS X Server _OG_ giver dem nogen gysser så vil de
gerne høre om dem.

Det skal så siges at der nok også kan være tekniske forskelle, men det
er der fx ikke på diverse Linuxvarianter.
--
Thorbjørn Ravn Andersen "... plus ... Tubular iMacs!"

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > OK, jeg har ingen erfaring med MacOS X Server, og ved kun at
> > serverversionen ville gøre det muligt for mig at køre Oracle. Ikke at
> > jeg ville ofte 4000 kroner på det ...
>
> Prøvede du overhovedet at installere Oracle på en non-server OS X?

Ja.

> At Oracle supporterer OS X Server men ikke OS X betyder bare at hvis
> du har problemer under OS X er Oracle ligeglad, men hvis du har
> problemer under OS X Server _OG_ giver dem nogen gysser så vil de
> gerne høre om dem.
>
> Det skal så siges at der nok også kan være tekniske forskelle, men det
> er der fx ikke på diverse Linuxvarianter.

Der er et installationsscript, som ganske simpelt ikke kan køres under
MacOS X, med mindre man går ned og retter i en scriptkode på et par
tusinde programlinier, hvis det er nok.

Fra starten går scriptet ned med fejl, fordi der ikke i systemet er
kataloger, som scriptet forventer er der. Man skal nok kende MacOS X
Server forholdsvist godt, for at kunne rette i scriptet, så den kan
installere Oracle på klienten.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne <per@rqnne.invalid> wrote:
> Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> > per@RQNNE.invalid (Per Rønne) writes:
> >
> > > OK, jeg har ingen erfaring med MacOS X Server, og ved kun at
> > > serverversionen ville gøre det muligt for mig at køre Oracle. Ikke at
> > > jeg ville ofte 4000 kroner på det ...
> >
> > Prøvede du overhovedet at installere Oracle på en non-server OS X?

> Ja.

> > At Oracle supporterer OS X Server men ikke OS X betyder bare at hvis
> > du har problemer under OS X er Oracle ligeglad, men hvis du har
> > problemer under OS X Server _OG_ giver dem nogen gysser så vil de
> > gerne høre om dem.
> >
> > Det skal så siges at der nok også kan være tekniske forskelle, men det
> > er der fx ikke på diverse Linuxvarianter.

> Der er et installationsscript, som ganske simpelt ikke kan køres under
> MacOS X, med mindre man går ned og retter i en scriptkode på et par
> tusinde programlinier, hvis det er nok.

> Fra starten går scriptet ned med fejl, fordi der ikke i systemet er
> kataloger, som scriptet forventer er der. Man skal nok kende MacOS X
> Server forholdsvist godt, for at kunne rette i scriptet, så den kan
> installere Oracle på klienten.

Jeg har vist engang tilbudt at rette scriptet for dig hvis du sender det
til mig - tilbudet står stadig ved magt.

--
Morten Reippuert Knudsen <http://blog.reippuert.dk>

Merlin Works CR-3/2.5 & Campagnolo Chorus 2007.

---

Morten Reippuert Knudsen <spam@reippuert.dk> wrote:

> Per Rønne <per@rqnne.invalid> wrote:
> > Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
>
> > > per@RQNNE.invalid (Per Rønne) writes:
> > >
> > > > OK, jeg har ingen erfaring med MacOS X Server, og ved kun at
> > > > serverversionen ville gøre det muligt for mig at køre Oracle. Ikke at
> > > > jeg ville ofte 4000 kroner på det ...
> > >
> > > Prøvede du overhovedet at installere Oracle på en non-server OS X?
>
> > Ja.
>
> > > At Oracle supporterer OS X Server men ikke OS X betyder bare at hvis
> > > du har problemer under OS X er Oracle ligeglad, men hvis du har
> > > problemer under OS X Server _OG_ giver dem nogen gysser så vil de
> > > gerne høre om dem.
> > >
> > > Det skal så siges at der nok også kan være tekniske forskelle, men det
> > > er der fx ikke på diverse Linuxvarianter.
>
> > Der er et installationsscript, som ganske simpelt ikke kan køres under
> > MacOS X, med mindre man går ned og retter i en scriptkode på et par
> > tusinde programlinier, hvis det er nok.
>
> > Fra starten går scriptet ned med fejl, fordi der ikke i systemet er
> > kataloger, som scriptet forventer er der. Man skal nok kende MacOS X
> > Server forholdsvist godt, for at kunne rette i scriptet, så den kan
> > installere Oracle på klienten.
>
> Jeg har vist engang tilbudt at rette scriptet for dig hvis du sender det
> til mig

Det har jeg vist ikke set.

> - tilbudet står stadig ved magt.

Jeg skal nok sende det til dig, når jeg har fundet det, og når jeg har
din e-mail adresse [virker spam-adressen?].
--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne <per@rqnne.invalid> wrote:
> Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:

> > Martin Schultz <news2005@adsltips.invalid> writes:
> >
> > > Taler vi om store "rigtige" database systemer (oracle, DB/2 osv) kommer
> > > det meget an på hvad man skal bruge den til, hvilket system den kan
> > > kører på og hvad en leverendør vil understøtte.
> >
> > Det skal lige siges at jeg så på et tidspunkt at der var nogen der
> > lavede performance målinger på OS X versus Linux og nåede frem til at
> > der var "et eller andet" i OS X der sløvede. Jeg kan ikke huske hvad,
> > men fandt følgende artikel som argumenterer for at visse ting i OS X
> > skal ske en af gangen, og altså ikke afvikles samtidig. Det er ikke
> > godt for ydelsen hvis der er flere CPU'er i.
> >
> > http://www.drunkenblog.com/drunkenblog-archives/000385.html
> >
> > Det var dog ikke det jeg så dengang, men det er da tankevækkende :)

> Er det bevidst at du skriver MacOS X og ikke MacOS X Server?

I dette tilfælde er der ingen forskel.
--
Morten Reippuert Knudsen <http://blog.reippuert.dk>

Merlin Works CR-3/2.5 & Campagnolo Chorus 2007.

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
> Martin Schultz <news2005@adsltips.invalid> writes:

> > Taler vi om store "rigtige" database systemer (oracle, DB/2 osv) kommer
> > det meget an på hvad man skal bruge den til, hvilket system den kan
> > kører på og hvad en leverendør vil understøtte.

> Det skal lige siges at jeg så på et tidspunkt at der var nogen der
> lavede performance målinger på OS X versus Linux og nåede frem til at
> der var "et eller andet" i OS X der sløvede. Jeg kan ikke huske hvad,
> men fandt følgende artikel som argumenterer for at visse ting i OS X
> skal ske en af gangen, og altså ikke afvikles samtidig. Det er ikke
> godt for ydelsen hvis der er flere CPU'er i.

> http://www.drunkenblog.com/drunkenblog-archives/000385.html

> Det var dog ikke det jeg så dengang, men det er da tankevækkende :)

Det er hådteringen af i/o der gør at mysql er sædeles langsom
på Mac OS X. Darwin har en udvidet funktion kaldet F_FULLFSYNC der i
modsætning til fsync verificere at data er skrevet og veneter på en
verificering før den registrerer data som værende skrevet og fortsætter.
Andre kerner, eks l9inux og NT kan kun hitte ud af fsync.

MySQL på Mac OS X bruger F_FULLFSYNC og ikke fsync som på linux,
hvilket gør at visse funktioner i mysql er stinkende langsomme på Mac
OS X.

Problemet eksisterer iøvrigt ikke andre databaser som Sybase, Oracle
eller PostgreSQL, dvs at der er tale om at mysql er ualmindelig ringe
optimeret til darwin og fornemt optimeret til linux. Man kunne også
sige at mysql udnytter darwin kernens funktionalitet med større
sikkehed på bekostning af hastighed ved I/O operationer.

Hele debatten startede med en test af en G5 på anantech som antog at
det var forking af theads der var problemet.
Efterfølgende debat på kernelthread fik anantech til at bechmarke Mac
OS X imod linux på samme hardware og med mysql bygget på forskellige
compilere (gcc 4.0 kontra 3.3).

Debatten om inflydelsen om hvorvidt en marginal langsommere forking af
threads kunne have så stor inflydelse i mysql, endte med at dawin
udviklere kom på banen og dementerede anandtechs påstand med
forklarimngen om fsync kontra F_FULLFSYNC, samt at dert blev opklaret
at mysql på darwin anvendet F_FULLFSYNC frem for fsync som på linux.

--
Morten Reippuert Knudsen <http://blog.reippuert.dk>

Merlin Works CR-3/2.5 & Campagnolo Chorus 2007.

---

Morten Reippuert Knudsen<spam@reippuert.dk> writes:

> Det er hådteringen af i/o der gør at mysql er sædeles langsom
> på Mac OS X. Darwin har en udvidet funktion kaldet F_FULLFSYNC der i

Tak for udredningen - jeg havde ikke set resten af historien siden de
målte de elendige tider med MySQL.

Har du eventuelt også set nogen vurderinger af OS X's skaleringsevne
med flere kerner/cpu'er?
--
Thorbjørn Ravn Andersen "... plus ... Tubular iMacs!"

---

Thorbjørn Ravn Andersen <nospam0000@gmail.com> wrote:
> Morten Reippuert Knudsen<spam@reippuert.dk> writes:

> > Det er hådteringen af i/o der gør at mysql er sædeles langsom
> > på Mac OS X. Darwin har en udvidet funktion kaldet F_FULLFSYNC der i

> Tak for udredningen - jeg havde ikke set resten af historien siden de
> målte de elendige tider med MySQL.

> Har du eventuelt også set nogen vurderinger af OS X's skaleringsevne
> med flere kerner/cpu'er?

det er den vist ganske glimragende til, i al fald til brug på
desktoppen. I sammenligning windows er der ingen konkunce.

Linux kernen er vist heller ikke videre imponerende på det punkt, omend
nogen af de komercielle distributioner har patches der forbedre SMP
ydelsen dramatisk.

I sammenligning med komercielle Unix'er kan darwin kernen vist ikke
klare sig.

--
Morten Reippuert Knudsen <http://blog.reippuert.dk>

Merlin Works CR-3/2.5 & Campagnolo Chorus 2007.