---

Hej igen, NG!

Er det muligt at søge i den tekst, der står i et BLOB-felt vha en
SQL-sætning?

Jeg har forsøgt med følgende:
qTest.SQL.Text := 'Select * from Ejendom where Kilder =
'+QuotedStr(Edit1.Text);
men det gav blot følgende fejlmelding:
Typemismatch in expression.

Feltet Kilder er et BLOB-felt.
Bruger jeg i stedet et andet 'almindeligt' felt virker det uden problemer.

Mvh Kurt

---

Prøv at skrive noget som:


Select * from Ejendom where Kilder Like = :PKilder

PKilder er så en parammeter, som skal overføres.
Den kan så sættes til f.eks.


MyQuery.ParamByName('PKilder').AsString := Edit1.Text+'%';

Michael


"Kurt Guldbæk" <kurt@guldbaek.net> skrev i en meddelelse
news:kbB7b.69947$Kb2.3162905@news010.worldonline.dk...
> Hej igen, NG!
>
> Er det muligt at søge i den tekst, der står i et BLOB-felt vha en
> SQL-sætning?
>
> Jeg har forsøgt med følgende:
> qTest.SQL.Text := 'Select * from Ejendom where Kilder =
> '+QuotedStr(Edit1.Text);
> men det gav blot følgende fejlmelding:
> Typemismatch in expression.
>
> Feltet Kilder er et BLOB-felt.
> Bruger jeg i stedet et andet 'almindeligt' felt virker det uden problemer.
>
> Mvh Kurt
>
>

---

Hej Michael.
Det vil jeg prøve.
Jeg ved dog ikke, hvad % i Edit1.Text+'%' står for!

Mvh Kurt


"Michael Vilhelmsen" <smom22@hotmail.com> skrev i en meddelelse
news:3f5f17db$0$29915$edfadb0f@dread11.news.tele.dk...
> Prøv at skrive noget som:
>
>
> Select * from Ejendom where Kilder Like = :PKilder
>
> PKilder er så en parammeter, som skal overføres.
> Den kan så sættes til f.eks.
>
>
> MyQuery.ParamByName('PKilder').AsString := Edit1.Text+'%';
>
> Michael
>
>
> "Kurt Guldbæk" <kurt@guldbaek.net> skrev i en meddelelse
> news:kbB7b.69947$Kb2.3162905@news010.worldonline.dk...
> > Hej igen, NG!
> >
> > Er det muligt at søge i den tekst, der står i et BLOB-felt vha en
> > SQL-sætning?
> >
> > Jeg har forsøgt med følgende:
> > qTest.SQL.Text := 'Select * from Ejendom where Kilder =
> > '+QuotedStr(Edit1.Text);
> > men det gav blot følgende fejlmelding:
> > Typemismatch in expression.
> >
> > Feltet Kilder er et BLOB-felt.
> > Bruger jeg i stedet et andet 'almindeligt' felt virker det uden
problemer.
> >
> > Mvh Kurt
> >
> >
>
>

---

"Kurt Guldbæk" <kurt@guldbaek.net> wrote in message
news:%MG7b.70206$Kb2.3171814@news010.worldonline.dk...
> Hej Michael.
> Det vil jeg prøve.
> Jeg ved dog ikke, hvad % i Edit1.Text+'%' står for!
>
> Mvh Kurt
>
>
Hej Kurt

% er egentlig det samme som du kender som * mange steder - altså
"Wildcards"..

Select * from Navne
WHERE Navn LIKE "Lena%"

Vil finde alle navne der starter med Lena

Select * from Navne
WHERE Navn LIKE "%Jensen"

Vil finde alle navne som ender på Jensen

Select * from Navne
WHERE Navn LIKE "%er%"

Vil finde alle navne, hvor "er" indgår i

Mvh
Ulrik

Ps. Jeg tror ikke du kan sammenligne på et blob felt, og jeg mener bare at
du gøre det samme med de 2 funktioner...

Hvorfor ik bruge et Memo ?

---

Tak for forklaringen til Ulrik.
Mvh Kurt

"Ulrik Vadstrup" <blackend@FJERNMIGblackend.dk> skrev i en meddelelse
news:bjnea8$1dt7$1@news.cybercity.dk...
> "Kurt Guldbæk" <kurt@guldbaek.net> wrote in message
> news:%MG7b.70206$Kb2.3171814@news010.worldonline.dk...
> > Hej Michael.
> > Det vil jeg prøve.
> > Jeg ved dog ikke, hvad % i Edit1.Text+'%' står for!
> >
> > Mvh Kurt
> >
> >
> Hej Kurt
>
> % er egentlig det samme som du kender som * mange steder - altså
> "Wildcards"..
>
> Select * from Navne
> WHERE Navn LIKE "Lena%"
>
> Vil finde alle navne der starter med Lena
>
> Select * from Navne
> WHERE Navn LIKE "%Jensen"
>
> Vil finde alle navne som ender på Jensen
>
> Select * from Navne
> WHERE Navn LIKE "%er%"
>
> Vil finde alle navne, hvor "er" indgår i
>
> Mvh
> Ulrik
>
> Ps. Jeg tror ikke du kan sammenligne på et blob felt, og jeg mener bare at
> du gøre det samme med de 2 funktioner...
>
> Hvorfor ik bruge et Memo ?
>
>

---

Kurt Guldbæk wrote:
> Er det muligt at søge i den tekst, der står i et BLOB-felt vha en
> SQL-sætning?

Du er landet i den forkerte nyhedsgruppe, og du har ikke angivet, hvilket
database system, du omtaler. Så svaret er:

Ja, i nogle database systemer kan man, i andre ikke.

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

Til NG!
Det må I meget undskylde, det er tankeløshed fra min side. Jeg fortsatte
blot ubevidst fra et andet spørgsmål jeg før har fået hjælp til.

Så vil jeg konkret spørge:
Jeg bruger Delphi5 og Paradox databaser.
Er det med de værktøjer muligt at søge i den tekst, der står i et BLOB-felt
vha en SQL-sætning eller vha. LookUp?

Kurt

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3f5f4393$0$29914$edfadb0f@dread11.news.tele.dk...
> Kurt Guldbæk wrote:
> > Er det muligt at søge i den tekst, der står i et BLOB-felt vha en
> > SQL-sætning?
>
> Du er landet i den forkerte nyhedsgruppe, og du har ikke angivet, hvilket
> database system, du omtaler. Så svaret er:
>
> Ja, i nogle database systemer kan man, i andre ikke.
>
> Lars.
>
> --
> Freelance programmør
> Delphi brugergruppen DAPUG: http://dapug.dk/
> Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

Kurt Guldbæk wrote:
> Jeg bruger Delphi5 og Paradox databaser.

Argh - lad være med det. Hop ind på http://www.dbisam.com/ og køb deres
produkt. Det er et system der er stort set magen til Paradox, bortset fra,
at:

1) Deres SQL er meget bedre (kan flere ting) og MEGET hurtigere.
2) Du slipper for BDE'en. DBISAM kompileres ind som en del af .exe filen.
3) Der er markant færre problemer på netværksdrev, og du slipper for at
sætte et netdir op.

Mig bekendt kan du ikke søge i blobfelter i Paradox med SQL, men du bør
sådan set også hellere bruge TTable komponenter med .SetRange(), .FindKey,
..IndexName og evt. .Filter i stedet for TQuery - performance er ekstremt
meget bedre, og du vil så selv kunne foretage søgningen.

Paradoxformatet er optimeret til TTable operationer og til QueryByExample.
SQL overbygningen er en dårlig lappeløsning og efter min mening ikke egnet
til produktionsbrug. Hvis du absolut vil bruge SQL, så overvej seriøst
DBISAM.

Overvej evt. også at stille spørgsmål om emnet til DAPUGs liste på
http://groups.yahoo.com/group/dapug. DAPUG er den gamle danske Paradox
brugergruppe, som så blev til den danske Delphi brugergruppe og nu er en
generel Database programmerings brugergruppe. Man behøver ikke at være
medlem for at stille spørgsmål til e-mail listen.

Hilsen,

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

Tak til Lars.

Jeg er blevet noget forvirret efterhånden. Jeg startede med at spørge på
brugen af LookUp for at finde nogle ting i databasen her i NG for et par
uger siden. Et af hintene jeg fik var at bruge SQL i stedet, man mente ikke,
at der var nævneværdig hastighedsforskelle. Nu fornemmer jeg at vi igen er
ovre i samme familie som LookUp hører til. Eller også har jeg efterhånden
helt mistet overblikket!

Mit projekt er egentlig et hobbyprojekt, selv om det er vokset lidt
efterhånden. Der er ikke nogen udsigt til at det skal bruges på net.
Jeg har pt ikke rigtig penge til at tilkøbe mere programmel, dette sagt uden
at jeg kender prisen på DBISAM.
Jeg har lige tre gange været inde på http://www.dbisam.com/ og fik hver
gang i stedet en reklameside for medikamenter
(http://www.medprescribe.com/). Hvad der er galt ved jeg ikke.

Jeg vil prøve at kikke på de der TTable-komponenter.

Mvh Kurt


"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3f5f8649$0$29946$edfadb0f@dread11.news.tele.dk...
> Kurt Guldbæk wrote:
> > Jeg bruger Delphi5 og Paradox databaser.
>
> Argh - lad være med det. Hop ind på http://www.dbisam.com/ og køb deres
> produkt. Det er et system der er stort set magen til Paradox, bortset fra,
> at:
>
> 1) Deres SQL er meget bedre (kan flere ting) og MEGET hurtigere.
> 2) Du slipper for BDE'en. DBISAM kompileres ind som en del af .exe filen.
> 3) Der er markant færre problemer på netværksdrev, og du slipper for at
> sætte et netdir op.
>
> Mig bekendt kan du ikke søge i blobfelter i Paradox med SQL, men du bør
> sådan set også hellere bruge TTable komponenter med .SetRange(), .FindKey,
> .IndexName og evt. .Filter i stedet for TQuery - performance er ekstremt
> meget bedre, og du vil så selv kunne foretage søgningen.
>
> Paradoxformatet er optimeret til TTable operationer og til QueryByExample.
> SQL overbygningen er en dårlig lappeløsning og efter min mening ikke egnet
> til produktionsbrug. Hvis du absolut vil bruge SQL, så overvej seriøst
> DBISAM.
>
> Overvej evt. også at stille spørgsmål om emnet til DAPUGs liste på
> http://groups.yahoo.com/group/dapug. DAPUG er den gamle danske Paradox
> brugergruppe, som så blev til den danske Delphi brugergruppe og nu er en
> generel Database programmerings brugergruppe. Man behøver ikke at være
> medlem for at stille spørgsmål til e-mail listen.
>
> Hilsen,
>
> Lars.
>
> --
> Freelance programmør
> Delphi brugergruppen DAPUG: http://dapug.dk/
> Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

"Kurt Guldbæk" <kurt@guldbaek.net> skrev i en meddelelse
news:HvM7b.70336$Kb2.3204032@news010.worldonline.dk...
> Tak til Lars.
>
> Jeg er blevet noget forvirret efterhånden. Jeg startede med at spørge på
> brugen af LookUp for at finde nogle ting i databasen her i NG for et par
> uger siden. Et af hintene jeg fik var at bruge SQL i stedet, man mente
ikke,
> at der var nævneværdig hastighedsforskelle. Nu fornemmer jeg at vi igen er
> ovre i samme familie som LookUp hører til. Eller også har jeg efterhånden
> helt mistet overblikket!
>
> Mit projekt er egentlig et hobbyprojekt, selv om det er vokset lidt
> efterhånden. Der er ikke nogen udsigt til at det skal bruges på net.
> Jeg har pt ikke rigtig penge til at tilkøbe mere programmel, dette sagt
uden
> at jeg kender prisen på DBISAM.
> Jeg har lige tre gange været inde på http://www.dbisam.com/ og fik hver
> gang i stedet en reklameside for medikamenter
> (http://www.medprescribe.com/). Hvad der er galt ved jeg ikke.
>
> Jeg vil prøve at kikke på de der TTable-komponenter.

Prøv at kikke på http://www.elevatesoft.com for at læse om dbisam.

Og så et spørgsmål til Lars, hvad er fordelene ved dbisam hvis man
sammenligner den med f.eks. MySQL og dbexpress?

Mvh
HK

---

Harald wrote:
> Og så et spørgsmål til Lars, hvad er fordelene ved dbisam hvis man
> sammenligner den med f.eks. MySQL og dbexpress?

Efter min overbevisning er der ingen grund til at interessere sig for
client/server udgaven af DBISAM. Det er ren marketing.

Men standard-udgaven har følgende fordele frem for dbexpress/MySQL:

- Alt ligger i en .exe fil. Ingen DLL'er, klientsoftware eller server
software er nødvendigt.
- Meget bedre performance end bl.a. MySQL ved kørsel på lokal harddisk.

Hvis man har lyst til at se, hvordan nemt et DBISAM baseret program kan være
at have med at gøre, så hent det lille kalenderprogram fra
http://sourceforge.net/projects/mkal/. Installationen er således:

1) Lav en ny mappe på et netværksdrev, f.eks. P:\kalender
2) Kopier .exe filen ind i mappen.
3) Lav en genvej til .exe filen fra alle de computere, der skal bruge
programmet.

Værsgo'... man behøver ikke engang at involvere edb-afdelingen eller have
administrator rettighed over sin egen computer. Programmet er selvflg. et
flerbruger program og det tog mig i alt 3 timer at udvikle for en kunde,
der valgte det til deres mødelokale reservation frem for at lave en fælles
kalender i Outlook.

Hvis man vil lave flere kalendere, så gentag ovenstående
installationsvejledning men kopier .exe filen til en anden mappe...

Når programmet har kørt, laver det en .ini fil. Denne kan man ændre, såfremt
man vil navngive sin kalender. Da kalenderen er baseret på DBISAM, kan den
nemt håndtere millioner af kalender entries med øjeblikkelig performance.
Det er først når man har prøvet at installere et sådan program, at man helt
forstår potentialet i DBISAM frem for Paradox (der kræver BDE) og mysql
(der kræver at man installerer eller konfigurerer/opsætter en mysql
database).

Hilsen,

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

"Kurt Guldbæk" <kurt@guldbaek.net> wrote in message
news:HvM7b.70336$Kb2.3204032@news010.worldonline.dk...
> Mit projekt er egentlig et hobbyprojekt, selv om det er vokset lidt
> efterhånden. Der er ikke nogen udsigt til at det skal bruges på net.
> Jeg har pt ikke rigtig penge til at tilkøbe mere programmel, dette
sagt uden
> at jeg kender prisen på DBISAM.

(249 $ er prisen)
Så hold fast ved paradox, så dårlig er den heller ikke.

> Jeg har lige tre gange været inde på http://www.dbisam.com/ og fik
hver
> gang i stedet en reklameside for medikamenter

Siden har tilhørt Elevatesoft tidligere, så Lars's link var ikke helt
tosset.

---

Hej Kurt

Gå ind på Mers.com og hent Interbase 6.0.2 den er gratis og
meget bedre end paradox!

Hilsen Thomas Riedel


"Kurt Guldbæk" <kurt@guldbaek.net> wrote in message
news:HvM7b.70336$Kb2.3204032@news010.worldonline.dk...
> Tak til Lars.
>
> Jeg er blevet noget forvirret efterhånden. Jeg startede med at spørge på
> brugen af LookUp for at finde nogle ting i databasen her i NG for et par
> uger siden. Et af hintene jeg fik var at bruge SQL i stedet, man mente
ikke,
> at der var nævneværdig hastighedsforskelle. Nu fornemmer jeg at vi igen er
> ovre i samme familie som LookUp hører til. Eller også har jeg efterhånden
> helt mistet overblikket!
>
> Mit projekt er egentlig et hobbyprojekt, selv om det er vokset lidt
> efterhånden. Der er ikke nogen udsigt til at det skal bruges på net.
> Jeg har pt ikke rigtig penge til at tilkøbe mere programmel, dette sagt
uden
> at jeg kender prisen på DBISAM.
> Jeg har lige tre gange været inde på http://www.dbisam.com/ og fik hver
> gang i stedet en reklameside for medikamenter
> (http://www.medprescribe.com/). Hvad der er galt ved jeg ikke.
>
> Jeg vil prøve at kikke på de der TTable-komponenter.
>
> Mvh Kurt
>
>
> "Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
> news:3f5f8649$0$29946$edfadb0f@dread11.news.tele.dk...
> > Kurt Guldbæk wrote:
> > > Jeg bruger Delphi5 og Paradox databaser.
> >
> > Argh - lad være med det. Hop ind på http://www.dbisam.com/ og køb deres
> > produkt. Det er et system der er stort set magen til Paradox, bortset
fra,
> > at:
> >
> > 1) Deres SQL er meget bedre (kan flere ting) og MEGET hurtigere.
> > 2) Du slipper for BDE'en. DBISAM kompileres ind som en del af .exe
filen.
> > 3) Der er markant færre problemer på netværksdrev, og du slipper for at
> > sætte et netdir op.
> >
> > Mig bekendt kan du ikke søge i blobfelter i Paradox med SQL, men du bør
> > sådan set også hellere bruge TTable komponenter med .SetRange(),
..FindKey,
> > .IndexName og evt. .Filter i stedet for TQuery - performance er ekstremt
> > meget bedre, og du vil så selv kunne foretage søgningen.
> >
> > Paradoxformatet er optimeret til TTable operationer og til
QueryByExample.
> > SQL overbygningen er en dårlig lappeløsning og efter min mening ikke
egnet
> > til produktionsbrug. Hvis du absolut vil bruge SQL, så overvej seriøst
> > DBISAM.
> >
> > Overvej evt. også at stille spørgsmål om emnet til DAPUGs liste på
> > http://groups.yahoo.com/group/dapug. DAPUG er den gamle danske Paradox
> > brugergruppe, som så blev til den danske Delphi brugergruppe og nu er en
> > generel Database programmerings brugergruppe. Man behøver ikke at være
> > medlem for at stille spørgsmål til e-mail listen.
> >
> > Hilsen,
> >
> > Lars.
> >
> > --
> > Freelance programmør
> > Delphi brugergruppen DAPUG: http://dapug.dk/
> > Delphi oversættelsesværktøjer: http://dxgettext.sf.net/
>
>

---

Eller bedre endnu.....

Hent Firebird.
Firebird er en videreudvikling af Interbase 6.0.2.
Det var nemlig kun ovenstående version af Interbase der var gratis, hvor
imod Firebird er og altid vil være gratis.

Og der er nogle udemærkede support forums på uahoo groups.

Og alt hvad du kan i Interbase kan du i Firebird (og mere til).

Michael
"Thor" <thr@image.danmark> skrev i en meddelelse
news:bjpjhk$c5b$1@news.cybercity.dk...
> Hej Kurt
>
> Gå ind på Mers.com og hent Interbase 6.0.2 den er gratis og
> meget bedre end paradox!
>
> Hilsen Thomas Riedel
>
>
> "Kurt Guldbæk" <kurt@guldbaek.net> wrote in message
> news:HvM7b.70336$Kb2.3204032@news010.worldonline.dk...
> > Tak til Lars.
> >
> > Jeg er blevet noget forvirret efterhånden. Jeg startede med at spørge på
> > brugen af LookUp for at finde nogle ting i databasen her i NG for et par
> > uger siden. Et af hintene jeg fik var at bruge SQL i stedet, man mente
> ikke,
> > at der var nævneværdig hastighedsforskelle. Nu fornemmer jeg at vi igen
er
> > ovre i samme familie som LookUp hører til. Eller også har jeg
efterhånden
> > helt mistet overblikket!
> >
> > Mit projekt er egentlig et hobbyprojekt, selv om det er vokset lidt
> > efterhånden. Der er ikke nogen udsigt til at det skal bruges på net.
> > Jeg har pt ikke rigtig penge til at tilkøbe mere programmel, dette sagt
> uden
> > at jeg kender prisen på DBISAM.
> > Jeg har lige tre gange været inde på http://www.dbisam.com/ og fik
hver
> > gang i stedet en reklameside for medikamenter
> > (http://www.medprescribe.com/). Hvad der er galt ved jeg ikke.
> >
> > Jeg vil prøve at kikke på de der TTable-komponenter.
> >
> > Mvh Kurt
> >
> >
> > "Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
> > news:3f5f8649$0$29946$edfadb0f@dread11.news.tele.dk...
> > > Kurt Guldbæk wrote:
> > > > Jeg bruger Delphi5 og Paradox databaser.
> > >
> > > Argh - lad være med det. Hop ind på http://www.dbisam.com/ og køb
deres
> > > produkt. Det er et system der er stort set magen til Paradox, bortset
> fra,
> > > at:
> > >
> > > 1) Deres SQL er meget bedre (kan flere ting) og MEGET hurtigere.
> > > 2) Du slipper for BDE'en. DBISAM kompileres ind som en del af .exe
> filen.
> > > 3) Der er markant færre problemer på netværksdrev, og du slipper for
at
> > > sætte et netdir op.
> > >
> > > Mig bekendt kan du ikke søge i blobfelter i Paradox med SQL, men du
bør
> > > sådan set også hellere bruge TTable komponenter med .SetRange(),
> .FindKey,
> > > .IndexName og evt. .Filter i stedet for TQuery - performance er
ekstremt
> > > meget bedre, og du vil så selv kunne foretage søgningen.
> > >
> > > Paradoxformatet er optimeret til TTable operationer og til
> QueryByExample.
> > > SQL overbygningen er en dårlig lappeløsning og efter min mening ikke
> egnet
> > > til produktionsbrug. Hvis du absolut vil bruge SQL, så overvej seriøst
> > > DBISAM.
> > >
> > > Overvej evt. også at stille spørgsmål om emnet til DAPUGs liste på
> > > http://groups.yahoo.com/group/dapug. DAPUG er den gamle danske Paradox
> > > brugergruppe, som så blev til den danske Delphi brugergruppe og nu er
en
> > > generel Database programmerings brugergruppe. Man behøver ikke at være
> > > medlem for at stille spørgsmål til e-mail listen.
> > >
> > > Hilsen,
> > >
> > > Lars.
> > >
> > > --
> > > Freelance programmør
> > > Delphi brugergruppen DAPUG: http://dapug.dk/
> > > Delphi oversættelsesværktøjer: http://dxgettext.sf.net/
> >
> >
>
>

---

Thor wrote:
> Gå ind på Mers.com og hent Interbase 6.0.2 den er gratis og
> meget bedre end paradox!

Her er jeg absolut uenig. Det kommer helt an på, hvad man vil. Interbase er
en SQL-baseret database og er kun velegnet til projekter, hvor man kan køre
SQL.

Paradox er til gengæld i stand til at håndtere koncepter som "den
efterfølgende record", "rækkefølge uden primary index" og ikke mindst en
gigantisk meget bedre hastighed en nogen SQL-baseret server nogensinde vil
kunne frembringe.

Så det kommer helt an på anvendelsen.

Hilsen,

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

Hej Lars

Jeg mener, det kommer an på størrelsen af databasen mht. hastigheden.

Vi benytter Firebird som DB, og vores DB er i størrelsen 10 Mb og op til
(lige nu) 7 Gb.

Det kører upåklageligt.. Den er hurtig og stabil.

Og med hensyn til efterfølgende record, rækkefælge m.m. kan Firebird det
hele.
Det er kun et spørgsmål om, hvordan man laver sine views, select m.m.

Og stored procedures er også en ganske udemærket funktion, som Firebird også
tilbyder.

Så det må man jo selv vurdere.. .. ..


Michael



"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3f60cf2c$0$209$edfadb0f@dread11.news.tele.dk...
> Thor wrote:
> > Gå ind på Mers.com og hent Interbase 6.0.2 den er gratis og
> > meget bedre end paradox!
>
> Her er jeg absolut uenig. Det kommer helt an på, hvad man vil. Interbase
er
> en SQL-baseret database og er kun velegnet til projekter, hvor man kan
køre
> SQL.
>
> Paradox er til gengæld i stand til at håndtere koncepter som "den
> efterfølgende record", "rækkefølge uden primary index" og ikke mindst en
> gigantisk meget bedre hastighed en nogen SQL-baseret server nogensinde vil
> kunne frembringe.
>
> Så det kommer helt an på anvendelsen.
>
> Hilsen,
>
> Lars.
>
> --
> Freelance programmør
> Delphi brugergruppen DAPUG: http://dapug.dk/
> Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

Michael Vilhelmsen wrote:
> Jeg mener, det kommer an på størrelsen af databasen mht. hastigheden.

O.k. - jeg vil gerne give dig ret i, at meget store databaser kan levere
data hurtigere, hvis du forespørger en lille datamængde, fordi de bedre
fremfindingsalgoritmer giver en performanceforbedring, der er større end
tabet i overhead på netværkstransmission og fortolkning af SQL
forespørgslen.

Men jeg har set Paradox løsninger på adskillige gigabytes, hvor svartiden
for fremhenting af mange data, fra forskellige tabeller, inklusiv billeder
fra blobfelter og visning af billederne m.v. var tydeligt under 0,1 sekund.
Og vi snakker her 200MHz maskiner med max 64MB RAM.

Årsagerne til den høje performance ved Paradox er efter min mening åbenlyse:

- Ingen resultat-dataset som følge af forespørgsler. Det bruger mindre RAM,
hvilket giver mere RAM til cache.
- Engine'en fylder stort set ikke noget i RAM sammenlignet med de fleste
moderne database servere. Det giver mere RAM til cache.
- Ingen transaktionssupport og ingen multithreading af database adgang
medfører at der anvendes meget simple algoritmer som afvikler hurtigt.
- Engine er en del af programmet, og der skal derfor ikke overføres data
mellem programmer (dette svarer til den MySQL support der findes til php på
Linux).
- Der er ingen SQL statements, der skal fortolkes. Det medfører, at der ikke
er fejlfortolkninger der medfører uindekserede søgninger, og selve
fortolkningen spares også væk.

Med andre ord: Det er så hammersimpelt, at al overhead er væk. Til gengæld
mangler man så også alle de avancerede features såsom beskyttelse af data
integritet, transkationer, flerbrugerfaciliteter osv.

De eneste problemer, som Paradox har performancemæssigt er:
- Hvis flere vil tilgå den samtidigt.
- Hvis programmøren ikke bruger indexes.
- Hvis datamængden er så stor, at Paradox'es 2-niveaus b-træ filstruktur har
en performance mæssig ulempe i forhold til større database systemers
mange-niveaus b-træ filstruktur.
- Hvis databasen ligger på et ikke-lokalt filsystem eller et filsystem der
tilhører en applikationsserver a la Citrix/Windows Terminal Services.

> Og med hensyn til efterfølgende record, rækkefælge m.m. kan Firebird det
> hele. Det er kun et spørgsmål om, hvordan man laver sine views, select
> m.m.

Jeg bruger selv Firebird til omtrent halvdelen af mine projekter, og jeg vil
give dig så meget ret, at man i Firebird klart bedre kan bruge koncepterne
"forrige" og "efterfølgende" record end f.eks. i MS SQL Server, men
alligevel ser jeg sjældent dette brugt i Firebird, normalt fordi det ikke
er særligt SQL venligt.

Den hyppigste anvendelse, som jeg har set mht. "forrige" og "efterfølgende"
begreberne, er når records har en tidsperiode, de er gyldige i. Denne her
er meget typisk: Man har en tabel med felterne:

kundenummer
tidspunkt
kreditrentesats

Hvis man her vil finde den historiske rentesats for en kunde for tidspunktet
x, skal man bare finde den kreditrentesats, hvor tidspunkt<=x og hvor
x<=tidspunktet i den efterfølgende record. Det er jo ekstremt banalt og
utroligt nemt at finde med TTable:

tbl.IndexName:=''; // Primary key
tbl.FindKey ([kundenummer]); { TODO : Husk fejlcheck }
while (not tbl.eof) and (tbl.FieldByName('Tidspunkt').AsDateTime<=x) do
tbl.Next;
if tbl.FieldByName('Tidspunkt').AsDateTime>x then
tbl.Prior;

Den slags smider man selvflg. ind i en procedure eller en function, så man
ikke skal skrive det alle de steder, hvor man har brug for at finde en
record på den måde. På Firebird kan man lave denne SQL:

select kreditrentesats
from rentesatser
where x>=tidspunkt and kundenummer=y

og så gennemløbe records på samme måde som i Paradox, men de fleste Firebird
løsninger, som jeg har set, er lavet ved at programmøren har forsøgt at
finde den helt rigtige record med et SQL statement. Og her bliver det lidt
mere kompliceret:

select kreditrentesats
from rentesatser
where kundenummer=y and tidspunkt in
(select max(tidspunkt) from rentesatser where kundenummer=y and
tidspunkt<=x)

Her vil de fleste nok vælge at indsætte et ekstra felt i Firebird databasen,
der angiver udløbstidspunktet for en record, så det kan klares med:

select kreditrentesats
from rentesatser
where kundenummer=y and tidspunkt<=x and x<udloeb

Og så er vi jo væk fra princippet om "næste" og "foregående".

> Og stored procedures er også en ganske udemærket funktion, som Firebird
> også tilbyder.

Firebird er et dejligt stykke software, det kan vi MEGET hurtigt blive enige
om. Det er klart min favorit database, og jeg forstår simpelthen ikke,
hvorfor et firma som Microsoft ikke kan tage bare lidt ved lære af Firebird
i deres uduelige Microsoft SQL Server, som jeg p.t. slås en hel del med.
Hvis bare Microsoft gad indbygge noget, der svarede til Firebird's
"generator" princip, ville man kunne spare mange timer på MSSQL Server, og
en notation som "NEW.Feltnavn=2;" i Firebird's triggere ville også være
guld værd.

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

Se, det lyder jo til, at vi i bund og grund er enige.

Alle de projekter sokm jeg har udviklet er flerbruger orienteret og kræver
transaktionsstyring, så det er i hvert fald endnu et argument mod paradox.

Michael

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3f62394e$0$191$edfadb0f@dread11.news.tele.dk...
> Michael Vilhelmsen wrote:
> > Jeg mener, det kommer an på størrelsen af databasen mht. hastigheden.
>
> O.k. - jeg vil gerne give dig ret i, at meget store databaser kan levere
> data hurtigere, hvis du forespørger en lille datamængde, fordi de bedre
> fremfindingsalgoritmer giver en performanceforbedring, der er større end
> tabet i overhead på netværkstransmission og fortolkning af SQL
> forespørgslen.
>
> Men jeg har set Paradox løsninger på adskillige gigabytes, hvor svartiden
> for fremhenting af mange data, fra forskellige tabeller, inklusiv billeder
> fra blobfelter og visning af billederne m.v. var tydeligt under 0,1
sekund.
> Og vi snakker her 200MHz maskiner med max 64MB RAM.
>
> Årsagerne til den høje performance ved Paradox er efter min mening
åbenlyse:
>
> - Ingen resultat-dataset som følge af forespørgsler. Det bruger mindre
RAM,
> hvilket giver mere RAM til cache.
> - Engine'en fylder stort set ikke noget i RAM sammenlignet med de fleste
> moderne database servere. Det giver mere RAM til cache.
> - Ingen transaktionssupport og ingen multithreading af database adgang
> medfører at der anvendes meget simple algoritmer som afvikler hurtigt.
> - Engine er en del af programmet, og der skal derfor ikke overføres data
> mellem programmer (dette svarer til den MySQL support der findes til php
på
> Linux).
> - Der er ingen SQL statements, der skal fortolkes. Det medfører, at der
ikke
> er fejlfortolkninger der medfører uindekserede søgninger, og selve
> fortolkningen spares også væk.
>
> Med andre ord: Det er så hammersimpelt, at al overhead er væk. Til gengæld
> mangler man så også alle de avancerede features såsom beskyttelse af data
> integritet, transkationer, flerbrugerfaciliteter osv.
>
> De eneste problemer, som Paradox har performancemæssigt er:
> - Hvis flere vil tilgå den samtidigt.
> - Hvis programmøren ikke bruger indexes.
> - Hvis datamængden er så stor, at Paradox'es 2-niveaus b-træ filstruktur
har
> en performance mæssig ulempe i forhold til større database systemers
> mange-niveaus b-træ filstruktur.
> - Hvis databasen ligger på et ikke-lokalt filsystem eller et filsystem der
> tilhører en applikationsserver a la Citrix/Windows Terminal Services.
>
> > Og med hensyn til efterfølgende record, rækkefælge m.m. kan Firebird det
> > hele. Det er kun et spørgsmål om, hvordan man laver sine views, select
> > m.m.
>
> Jeg bruger selv Firebird til omtrent halvdelen af mine projekter, og jeg
vil
> give dig så meget ret, at man i Firebird klart bedre kan bruge koncepterne
> "forrige" og "efterfølgende" record end f.eks. i MS SQL Server, men
> alligevel ser jeg sjældent dette brugt i Firebird, normalt fordi det ikke
> er særligt SQL venligt.
>
> Den hyppigste anvendelse, som jeg har set mht. "forrige" og
"efterfølgende"
> begreberne, er når records har en tidsperiode, de er gyldige i. Denne her
> er meget typisk: Man har en tabel med felterne:
>
> kundenummer
> tidspunkt
> kreditrentesats
>
> Hvis man her vil finde den historiske rentesats for en kunde for
tidspunktet
> x, skal man bare finde den kreditrentesats, hvor tidspunkt<=x og hvor
> x<=tidspunktet i den efterfølgende record. Det er jo ekstremt banalt og
> utroligt nemt at finde med TTable:
>
> tbl.IndexName:=''; // Primary key
> tbl.FindKey ([kundenummer]); { TODO : Husk fejlcheck }
> while (not tbl.eof) and (tbl.FieldByName('Tidspunkt').AsDateTime<=x) do
> tbl.Next;
> if tbl.FieldByName('Tidspunkt').AsDateTime>x then
> tbl.Prior;
>
> Den slags smider man selvflg. ind i en procedure eller en function, så man
> ikke skal skrive det alle de steder, hvor man har brug for at finde en
> record på den måde. På Firebird kan man lave denne SQL:
>
> select kreditrentesats
> from rentesatser
> where x>=tidspunkt and kundenummer=y
>
> og så gennemløbe records på samme måde som i Paradox, men de fleste
Firebird
> løsninger, som jeg har set, er lavet ved at programmøren har forsøgt at
> finde den helt rigtige record med et SQL statement. Og her bliver det lidt
> mere kompliceret:
>
> select kreditrentesats
> from rentesatser
> where kundenummer=y and tidspunkt in
> (select max(tidspunkt) from rentesatser where kundenummer=y and
> tidspunkt<=x)
>
> Her vil de fleste nok vælge at indsætte et ekstra felt i Firebird
databasen,
> der angiver udløbstidspunktet for en record, så det kan klares med:
>
> select kreditrentesats
> from rentesatser
> where kundenummer=y and tidspunkt<=x and x<udloeb
>
> Og så er vi jo væk fra princippet om "næste" og "foregående".
>
> > Og stored procedures er også en ganske udemærket funktion, som Firebird
> > også tilbyder.
>
> Firebird er et dejligt stykke software, det kan vi MEGET hurtigt blive
enige
> om. Det er klart min favorit database, og jeg forstår simpelthen ikke,
> hvorfor et firma som Microsoft ikke kan tage bare lidt ved lære af
Firebird
> i deres uduelige Microsoft SQL Server, som jeg p.t. slås en hel del med.
> Hvis bare Microsoft gad indbygge noget, der svarede til Firebird's
> "generator" princip, ville man kunne spare mange timer på MSSQL Server, og
> en notation som "NEW.Feltnavn=2;" i Firebird's triggere ville også være
> guld værd.
>
> Lars.
>
> --
> Freelance programmør
> Delphi brugergruppen DAPUG: http://dapug.dk/
> Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

Michael Vilhelmsen wrote:
> Alle de projekter sokm jeg har udviklet er flerbruger orienteret og kræver
> transaktionsstyring, så det er i hvert fald endnu et argument mod paradox.

Det er ikke et argument "mod paradox". Dine krav medfører bare, at det ville
være en fejl at vælge Paradox til dit projekt.

Det hele drejer sig om at bruge det rette værktøj til det rette formål.

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

Jamen så har jeg jeg lige et helt andet sprøgsmål

Hvis du har benyttet dig af Firebird (eller Interbase), hvilke comp. bruger
du så til at "connecte" med ?
Jeg bruger selv både BDE og IBX.
BDE'en er godt nok "dum" at have med at gøre, men det er ikke lige sådan at
skifte.

Så har jeg kigget meget på IBO, som virker enormt gode.

Også er jeg lige begyndt at kigge på FIBPlus.

Michael
"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3f65ed1a$0$152$edfadb0f@dread11.news.tele.dk...
> Michael Vilhelmsen wrote:
> > Alle de projekter sokm jeg har udviklet er flerbruger orienteret og
kræver
> > transaktionsstyring, så det er i hvert fald endnu et argument mod
paradox.
>
> Det er ikke et argument "mod paradox". Dine krav medfører bare, at det
ville
> være en fejl at vælge Paradox til dit projekt.
>
> Det hele drejer sig om at bruge det rette værktøj til det rette formål.
>
> Lars.
>
> --
> Freelance programmør
> Delphi brugergruppen DAPUG: http://dapug.dk/
> Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

Michael Vilhelmsen wrote:
> Hvis du har benyttet dig af Firebird (eller Interbase), hvilke comp.
> bruger du så til at "connecte" med ?

Jeg bruger IBX. Når Firebird 1.5 er udkommet vil jeg overveje at kigge lidt
på IBO, da IBX nok ikke kommer til at supportere Firebird-specifikke
features.

Jeg har tidligere brugt dbExpress (i forb. med Kylix), men fik datatab på
mystiske tidspunkter. Komponenterne virker ikke særlig deterministiske,
eller også opstår problemet kun ved datamængder over en vis størrelse (jeg
arbejder med databaser på flere gigabytes i 64-bit udgaven af firebird).
Efter at jeg har fundet ud af, at problemet rent faktisk er dbExpress, er
jeg meget nervøs for at bruge det igen - heldigvis findes IBX nu til Kylix.

> Jeg bruger selv både BDE og IBX.
> BDE'en er godt nok "dum" at have med at gøre, men det er ikke lige sådan
> at skifte.

Surt... BDE er ikke velegnet her.

> Også er jeg lige begyndt at kigge på FIBPlus.

Dem kender jeg ikke.

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

>
> > Jeg bruger selv både BDE og IBX.
> > BDE'en er godt nok "dum" at have med at gøre, men det er ikke lige sådan
> > at skifte.
>
> Surt... BDE er ikke velegnet her.

Enig.
Derfor skal er vi skiftet med nogle produkter til IBO, andre skal vi have
skiftet.


>
> > Også er jeg lige begyndt at kigge på FIBPlus.
>
> Dem kender jeg ikke.

Det skulle være en IBX arv art.
Dvs. når man nu kender IBX ganske godt, skulle FIB være lige til at gå til.
Tror jeg.
Jeg er lige ved at undersøge noget sammen med dem .

Søg på FIBPlus i google så kommer de frem (www.devrace.com eller sådan
noget).


Bruger du Firebird meget ?

Michael

---

Michael Vilhelmsen wrote:
> Bruger du Firebird meget ?

Ja. Jeg bruger det både til egne projekter og nogle
dataopsamlingssystemer/data mining systemer, hvor vi har solgt omkring
50-100 database servere. Jeg tror at den største er på 2-4 Gigabyte nu, men
de vokser støt og roligt alle sammen i størrelse, så jeg påregner at de
nuværende systemer skal kunne tåle 20 Gigabyte eller mere før de går på
pension. Database serverne er Pentium 500MHz maskiner med 64-128MB RAM, alt
efter model, og svartiderne er perfekte.

Desuden bruger jeg også Firebird i forbindelse med nogle webprojekter - hvis
man vil have transaktioner, så er Firebird stort set det eneste rigtige, da
den ikke ligesom Microsoft SQL Server m.v. låser noget som helst, samt
fordi responstiden for første record normalt er rigtig, rigtig god.

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> wrote in message
news:3f65ed1a$0$152$edfadb0f@dread11.news.tele.dk...

>
> Det hele drejer sig om at bruge det rette værktøj til det rette formål.
>
> Lars.
>

Jeg er gået hele den tunge, vanskelige vej bort fra Paradox over til
Interbase.
Det er, som du ved, lidt af et mareridt at få store Ttable objekter til at
køre under
under Interbase. Men idag bruger jeg udelukkende Interbase:
Performance er ganske vist dårligere på enkeltbruger systemer, men omvendt,
performance er aldrig et problem på enkeltbrugersystemer.
Det værste ved Paradox er, at det laver unoder, f.eks ændrer er
Autoincrement felt sig
af og til til et integer felt. (Kun NT/2000). Ved strømafbrydelser knækker
databasen ned
med korrupte index til følge. Netværksopsætningen er mystisk, og advarer
ikke
mod local share problematikken.
SQL forespørgsler går i uendelig løkke hvis de er for komplekse.
Alt i alt, - jeg går nu fra kunde til kunde og konverterer til Interbase,
også enkeltbrugersystemerne, for det gør systemerne mere pålidelige.

Det rette værktøj til den aktuelle opgave?
Yes, - Delphi og Interbase/FireBird til ALLE opgaver!

mvh /Thor

---

Kurt Guldbæk wrote:
> Et af hintene jeg fik var at bruge SQL i stedet, man mente ikke,
> at der var nævneværdig hastighedsforskelle.

Det gælder for alle de database typer, hvor adgang til data baserer sig på
SQL. Det gælder f.eks. Interbase, Firebird, Microsoft SQL Server, ODBC osv.

Men ved Paradox er det lige omvendt - her udgår SQL-delen er meget dårlig
overbygning på TTable princippet. Det tager cirka lige så lang tid at
gennemløbe en tabel med TTable som harddisken kan levere filen til RAM -
men TQuery er en kompliceret proces med ekstra midlertidige filer og andet
sjov som kræver en masse skrivning til harddisk (også ved select
statements), og som er ekstremt langsomt i sammenligning på Paradox filer.

Nøglen til høj performance på TTable er i øvrigt:
TTable.IndexName:=...
TTable.FindKey([xxx,yyy]);
TTable.Filter:=...

og så overbygningerne, som bygger på ovenstående:
TTable.SetRange([xxx,yyy],[,æææ]); (husk .CancelRange i en
try...finally...end)
TTable.Locate ()

> Mit projekt er egentlig et hobbyprojekt, selv om det er vokset lidt
> efterhånden. Der er ikke nogen udsigt til at det skal bruges på net.

Så hold dig til Paradox filformatet.

> at jeg kender prisen på DBISAM.

Den koster $249.

> Jeg har lige tre gange været inde på http://www.dbisam.com/ og fik hver
> gang i stedet en reklameside for medikamenter
> (http://www.medprescribe.com/). Hvad der er galt ved jeg ikke.

De har åbenbart solgt domænenavnet, for dbisam.com var tidligere
velfungerende. Men deres officielle hjemmeside, som er lidt sværere at
huske, er:

http://www.elevatesoft.com/

Hilsen,

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3f60ce6e$0$209$edfadb0f@dread11.news.tele.dk...
> Kurt Guldbæk wrote:
> > Et af hintene jeg fik var at bruge SQL i stedet, man mente ikke,
> > at der var nævneværdig hastighedsforskelle.
>
> Det gælder for alle de database typer, hvor adgang til data baserer sig på
> SQL. Det gælder f.eks. Interbase, Firebird, Microsoft SQL Server, ODBC
osv.
>
> Men ved Paradox er det lige omvendt - her udgår SQL-delen er meget dårlig
> overbygning på TTable princippet. Det tager cirka lige så lang tid at
> gennemløbe en tabel med TTable som harddisken kan levere filen til RAM -
> men TQuery er en kompliceret proces med ekstra midlertidige filer og andet
> sjov som kræver en masse skrivning til harddisk (også ved select
> statements), og som er ekstremt langsomt i sammenligning på Paradox filer.
>
> Nøglen til høj performance på TTable er i øvrigt:
> TTable.IndexName:=...
> TTable.FindKey([xxx,yyy]);
> TTable.Filter:=...

I følge de test jeg før har lavet og en jeg lige har lavet så er SQL over
dobbelt så hurtig at bruge end som filter på padadox tabeller.

/HK

> og så overbygningerne, som bygger på ovenstående:
> TTable.SetRange([xxx,yyy],[,æææ]); (husk .CancelRange i en
> try...finally...end)
> TTable.Locate ()
>
> > Mit projekt er egentlig et hobbyprojekt, selv om det er vokset lidt
> > efterhånden. Der er ikke nogen udsigt til at det skal bruges på net.
>
> Så hold dig til Paradox filformatet.
>
> > at jeg kender prisen på DBISAM.
>
> Den koster $249.
>
> > Jeg har lige tre gange været inde på http://www.dbisam.com/ og fik
hver
> > gang i stedet en reklameside for medikamenter
> > (http://www.medprescribe.com/). Hvad der er galt ved jeg ikke.
>
> De har åbenbart solgt domænenavnet, for dbisam.com var tidligere
> velfungerende. Men deres officielle hjemmeside, som er lidt sværere at
> huske, er:
>
> http://www.elevatesoft.com/
>
> Hilsen,
>
> Lars.
>
> --
> Freelance programmør
> Delphi brugergruppen DAPUG: http://dapug.dk/
> Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

Harald wrote:
> I følge de test jeg før har lavet og en jeg lige har lavet så er SQL over
> dobbelt så hurtig at bruge end som filter på padadox tabeller.

Filter er en ikke indekseret søgning. Den bør aldrig bruges som primær
funktion. Hvis man f.eks. vil have alle personer der bor i postnummer 2800,
så skal koden være:

tbl.IndexName:='IdxByPostnr';
tbl.FindNearest (['2800']);
while (not tbl.eof) and (tbl.FieldByName('Postnr').AsString='2800') do begin
// Gør noget
tbl.Next;
end;

Man kan så bruge filter til eventuelle ekstra betingelser, men man skal
altid bruge findkey, findnearest eller setrange på de primære betingelser.

Hvis du laver en SQL forespørgsel på noget, hvor der ikke findes et indeks,
svarer det til, at en TTable gennemløbes fra ende til anden og de matchende
records kopieres over i en anden TTable. Du vil kunne fremstille en
benchmark, der viser, at det er hurtigere at køre i en kopi af de relevante
records i en anden TTable (SQL metoden), end at køre i original tabellen
med filter. Men det ændrer ikke på, at alt, hvad der med Paradox filer kan
laves i SQL, kan gøres hurtigere med TTable komponenter.

Lars.

--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> wrote in message
news:3f5f8649$0$29946$edfadb0f@dread11.news.tele.dk...
> Kurt Guldbæk wrote:
>
> Mig bekendt kan du ikke søge i blobfelter i Paradox med SQL, men du bør
> sådan set også hellere bruge TTable komponenter med .SetRange(), .FindKey,
> .IndexName og evt. .Filter i stedet for TQuery - performance er ekstremt
> meget bedre, og du vil så selv kunne foretage søgningen.
>

Er det ikke lidt groft sat op, det vil vel afhænge af størrelsen af din
database. Hvis du bruger TTable "selecter" du vel konsekvent hele databasen,
og søger i den - eller tager jeg fejl ?

Jeg hælder stadig til SQL, da jeg syens det giver bedre muligheder - og jeg
tror egentlig stadig på det er hurtigere - på samme DB, sammenlignet med
TTable. Personlig kunne jeg aldrig drømme om at bruge Filter f.eks.

Kurt - Vær også opmærksom på den funktion der hedder Locate - på din TQuery
component - et stærk funktion

Query1.locate('Det du søger', 'navn på kolonne',[]);

/Ulrik

---

Ulrik Vadstrup wrote:
> Er det ikke lidt groft sat op, det vil vel afhænge af størrelsen af din
> database.

Jo større database, jo mindre bliver performance ved anvendelse af SQL.

> Hvis du bruger TTable "selecter" du vel konsekvent hele databasen,
> og søger i den - eller tager jeg fejl ?

Ja. En TTable svarer til at tabel-filen åbnes, og der så peges direkte i
filen. Når man bruger SQL på Paradox, svarer det til at der bruges to
TTable komponenter per forespørgsel, hvor den ene kigger i datatabellen, og
den anden bruges til at oprette en midlertidig tabel på harddisken.

Hvis man gennemsøger 1.000 records ud af 10.000 i en tabel, så vil TTable
metoden læse 10% af datatabellen, hvorimod TQuery vil oprette en ny fil på
harddisken, kopiere 10% af datatabellen derover i, rode lidt rundt i den og
bagefter slette filen igen.

> Jeg hælder stadig til SQL, da jeg syens det giver bedre muligheder

Så har du ikke prøvet at udnytte alle TTable faciliteterne. Performance
forskellen mellem TTable og TQuery kan, alt efter maskine og datamængde,
være over en faktor 1.000. Dette er ikke en joke. Jeg har f.eks. reduceret
tidsforbruget i et simpelt klient program med under 100kbyte data fra at
bruge et par minutter på at lave noget statistik på en tabel til at bruge
under 0,1 sekund på præcist det samme, bare ved at udskifte TQuery
komponenter med en TTable.

Men det er da rigtigt, at TQuery er hurtigere på SQL-baserede servere,
f.eks. via ODBC, men hertil hører Paradox ikke.

Lars.


--
Freelance programmør
Delphi brugergruppen DAPUG: http://dapug.dk/
Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> wrote in message
news:3f60cc9f$0$200$edfadb0f@dread11.news.tele.dk...
>
> Jo større database, jo mindre bliver performance ved anvendelse af SQL.
>
>
> Så har du ikke prøvet at udnytte alle TTable faciliteterne. Performance
> forskellen mellem TTable og TQuery kan, alt efter maskine og datamængde,
> være over en faktor 1.000. Dette er ikke en joke. Jeg har f.eks. reduceret
> tidsforbruget i et simpelt klient program med under 100kbyte data fra at
> bruge et par minutter på at lave noget statistik på en tabel til at bruge
> under 0,1 sekund på præcist det samme, bare ved at udskifte TQuery
> komponenter med en TTable.
>
> Men det er da rigtigt, at TQuery er hurtigere på SQL-baserede servere,
> f.eks. via ODBC, men hertil hører Paradox ikke.
>
> Lars.
> --
> Freelance programmør
> Delphi brugergruppen DAPUG: http://dapug.dk/
> Delphi oversættelsesværktøjer: http://dxgettext.sf.net/

Oki, det er nok fordi jeg mest har udviklet til Oracle og MSSQL og aldrig
brugt Paradox.

Det er nok der sagens kerne ligger

Ulrik

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3f5f8649$0$29946$edfadb0f@dread11.news.tele.dk...
> Kurt Guldbæk wrote:
> > Jeg bruger Delphi5 og Paradox databaser.
>
> Argh - lad være med det. Hop ind på http://www.dbisam.com/ og køb deres
> produkt. Det er et system der er stort set magen til Paradox, bortset fra,
> at:

Det er jo ikke noget svar! Hvordan gør jeg det og det? Svar : Køb et andet
produkt!

Her er svaret

select fielda,fieldb,fieldc,fieldxx from tablexxx where blobfieldxxx like
"%nogettekst%"

> Mig bekendt kan du ikke søge i blobfelter i Paradox med SQL,

Like er omfattet af "localsql", som Paradox-varianten benæves.

---

Til alle jer, der har svaret mig og hinanden.

Jeg takker for alle svarene; nogle gjorde mig forvirret på et højere/andet
plan og andre sagde mig noget.

Jeg har besluttet at fortsætte med Paradox lidt endnu. På længere sigt vil
jeg prøve en af de databaser, der indlejres i exe-filen. Den skal dog helst
være gratis, jeg har jo ingen kunder til at betale i sidste ende!

Jeg har vha SQL hentet teksten ud af BLOB-felterne og derefter søger jeg på
dem. Det kan bruges og så får jeg se hvornår det bliver for langsomt.

Dette er ikke skrevet for at afslutte synspunkterne ang. databaser mm, blot
for at sige tak.

Mvh Kurt