---

Hej NG!
Jeg har stadig problemer med 'Indexfile out of date'.
Jeg har nogle databasetabeller, som jeg vha DatabaseDesktop har oprettet
indexfiler til.
Derefter virker programmet OK med sammenkædningen af diverse databaser.
Når jeg i runtime indsætter nye records i disse databaser kommer programmet
næste gang der er brug for databaserne med fejlmeldingen 'Indexfile out of
date'.
Mine spørgsmål er nu:
Skal jeg selv gøre noget for at få indexfilerne til at passe?
Skal jeg oprette Indexfiler hver gang jeg vha programmet
ændrer/indsætter/fjerner records?
Er der nogen måder at omgå problemet på?
--
Med venlig hilsen
Kurt Guldbæk

---

Hej Kurt


Du kan gendanne index med Tutil32.exe som kan hentes flere steder på nettet.


mvh Thor

"Kurt Guldbæk" <kurt_g@guldbaek.net> skrev i en meddelelse
news:406ec33c$0$476$edfadb0f@dread14.news.tele.dk...
> Hej NG!
> Jeg har stadig problemer med 'Indexfile out of date'.
> Jeg har nogle databasetabeller, som jeg vha DatabaseDesktop har oprettet
> indexfiler til.
> Derefter virker programmet OK med sammenkædningen af diverse databaser.
> Når jeg i runtime indsætter nye records i disse databaser kommer
programmet
> næste gang der er brug for databaserne med fejlmeldingen 'Indexfile out of
> date'.
> Mine spørgsmål er nu:
> Skal jeg selv gøre noget for at få indexfilerne til at passe?
> Skal jeg oprette Indexfiler hver gang jeg vha programmet
> ændrer/indsætter/fjerner records?
> Er der nogen måder at omgå problemet på?
> --
> Med venlig hilsen
> Kurt Guldbæk
>
>
>

---

"Thor" <thor@thor.thor> skrev i en meddelelse
news:c4n30u$30d2$1@news.cybercity.dk...
> Hej Kurt
>
>
> Du kan gendanne index med Tutil32.exe som kan hentes flere steder på
nettet.
>
>
> mvh Thor
>
> "Kurt Guldbæk" <kurt_g@guldbaek.net> skrev i en meddelelse
> news:406ec33c$0$476$edfadb0f@dread14.news.tele.dk...
> > Hej NG!
> > Jeg har stadig problemer med 'Indexfile out of date'.
> > Jeg har nogle databasetabeller, som jeg vha DatabaseDesktop har oprettet
> > indexfiler til.
> > Derefter virker programmet OK med sammenkædningen af diverse databaser.
> > Når jeg i runtime indsætter nye records i disse databaser kommer
> programmet
> > næste gang der er brug for databaserne med fejlmeldingen 'Indexfile out
of
> > date'.
> > Mine spørgsmål er nu:
> > Skal jeg selv gøre noget for at få indexfilerne til at passe?
> > Skal jeg oprette Indexfiler hver gang jeg vha programmet
> > ændrer/indsætter/fjerner records?
> > Er der nogen måder at omgå problemet på?
> > --
> > Med venlig hilsen
> > Kurt Guldbæk
> >
> >
> >

Tak til Thor, jeg fandt filen et enkelt sted.
Men det var nu rarest, om jeg kunne undgå at skulle reparere indexfilerne,
for det sker hver gang jeg indsætter nye records. Et eller andet må jeg jo
gøre galt!
--
Med venlig hilsen
Kurt Guldbæk

---

Kurt Guldbæk wrote:

> Tak til Thor, jeg fandt filen et enkelt sted.
> Men det var nu rarest, om jeg kunne undgå at skulle reparere indexfilerne,
> for det sker hver gang jeg indsætter nye records. Et eller andet må jeg jo
> gøre galt!

Hvis det sker ved hver record, er der noget rivende galt.
Det er godt nok lang tid siden, jeg sidst brugte paradox, men jeg synes at
huske noget om, at det måske var en forkert fejlmelding, og problemet i
virkeligheden var noget helt andet.
Hvis du beskriver lidt om din recordstruktur, samt smider noget kode, helst
der, hvor det fejler, kan du nok få mere kvalificeret hjælp.

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <aaa@bbb.com> skrev i en meddelelse
news:c4pd4g$2rc$1@sunsite.dk...
> Kurt Guldbæk wrote:
>
> > Tak til Thor, jeg fandt filen et enkelt sted.
> > Men det var nu rarest, om jeg kunne undgå at skulle reparere
indexfilerne,
> > for det sker hver gang jeg indsætter nye records. Et eller andet må jeg
jo
> > gøre galt!
>
> Hvis det sker ved hver record, er der noget rivende galt.
> Det er godt nok lang tid siden, jeg sidst brugte paradox, men jeg synes at
> huske noget om, at det måske var en forkert fejlmelding, og problemet i
> virkeligheden var noget helt andet.
> Hvis du beskriver lidt om din recordstruktur, samt smider noget kode,
helst
> der, hvor det fejler, kan du nok få mere kvalificeret hjælp.

Ja jeg har også kørt med BDE og paradox tabeller siden delphi 4 tilbage i
1998. Jeg har en del programmer ude og kører som benytter paradox og har
gennem disse ca. 6 år kun oplevede problemet med 'Indexfile out of date'
nogle få gange og hver gang har det været pga. harddisk fejl eller
strømsvigt.

Mvh
HK

---

Harald wrote:

> Ja jeg har også kørt med BDE og paradox tabeller siden delphi 4 tilbage i
> 1998. Jeg har en del programmer ude og kører som benytter paradox og har
> gennem disse ca. 6 år kun oplevede problemet med 'Indexfile out of date'
> nogle få gange og hver gang har det været pga. harddisk fejl eller
> strømsvigt.

Ja, det er også sådan noget tænkte. Det må være noget andet i Kurt's
tilfælde.
Jeg synes jeg kan huske der var noget med brug af datoer/floats i indexer.
Eller også var det noget med, recorden var ændret et andet sted, og gav
denne lidt misvisende fejl.

Vi bliver nok nødt til at få lidt flere oplysninger af Kurt.

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <aaa@bbb.com> skrev i en meddelelse
news:c4phri$6f6$1@sunsite.dk...
> Harald wrote:
>
> > Ja jeg har også kørt med BDE og paradox tabeller siden delphi 4 tilbage
i
> > 1998. Jeg har en del programmer ude og kører som benytter paradox og har
> > gennem disse ca. 6 år kun oplevede problemet med 'Indexfile out of date'
> > nogle få gange og hver gang har det været pga. harddisk fejl eller
> > strømsvigt.
>
> Ja, det er også sådan noget tænkte. Det må være noget andet i Kurt's
> tilfælde.
> Jeg synes jeg kan huske der var noget med brug af datoer/floats i indexer.
> Eller også var det noget med, recorden var ændret et andet sted, og gav
> denne lidt misvisende fejl.
>
> Vi bliver nok nødt til at få lidt flere oplysninger af Kurt.
>
> --
> Med venlig hilsen
> Stig Johansen

Jeg vil prøve at konkretisere det lidt mere:

Filstruktur:
--Ejendomme
|_Tbl Her kopieres de nye filer til
|
|_Admin
| |__Tbl Her ligger kildefilerne

Jeg starter med vha Database DeskTop blandt flere at lave en database kaldet
Adresser.db. Ligeledes laves der nogle sekundære Index. Disse filer ligger
under Ejendomme_Admin_Tbl.

Under Ejendomme_Admin_Tbl har jeg nogle (amts)adresseregistre på ialt ca.
73MB dækkende hele landet. For ikke at få unødvendigt store filer at arbejde
med laver jeg nogle opslag og gemmer data for een eller flere kommuner i
Adresser.db.
Der udfyldes nogle flere databaser til forskellige andre opslag.
Inden opslagene begynder, har jeg tømt Adresser.db vha 'EmptyTable'. Til at
fylde i filen bruges 'Append'.

Derefter kopierer jeg vha. FileCopy databaserne samt indexfilerne over i
Ejendomme_Tbl.

Det er her det går galt. Databaserne virker godtnok indtil jeg med Object
Inskector vil koble dem sammen.
MasterSource kan jeg godt vælge. Når jeg så vil vælge enten IndexFiles eller
IndexName kommer fejlmeldingen 'Index out of date' og navnet på det
pågældende index.

Eksemplet er kortet lidt ned.
//Udfyld Adresser.db
editStatus.Text := 'Laver Adresser.db';
Update; //For at få tekst vist
Streng1 := 'Amt'+tblAmter.FieldByName('AmtNr').AsString+'_adresse';
//Lav navn på amtsdatafilen
tblKMS_Adresser.Close;
tblKMS_Adresser.TableName := Streng1; //Vælg datafilen
tblKMS_Adresser.Open;
tblKMS_Adresser.First;
while not tblKMS_Adresser.EOF do //Kik i KMS-filen
begin
Application.ProcessMessages;
If StopFlag Then
Begin
Screen.Cursor := crDefault;
Exit;
End;
If tblKMS_Adresser.FieldByName('KommNr').AsString = KommuneNr Then
Begin
Inc(AntalAdresser);
EditAntalAdresser.Text := IntToStr(AntalAdresser);
Application.ProcessMessages; //Vis tekst
If StopFlag Then
Begin
Screen.Cursor := crDefault;
Exit;
End;
tblAdresser.Append;
tblAdresser.FieldByName('KommNr').AsString :=
tblKMS_Adresser.FieldByName('KommNr').AsString;
...............Flere af samme slags.
tblAdresser.Post;
End;
tblKMS_Adresser.Next;
End; //While
EditAntalAdresser.Text := IntToStr(AntalAdresser);
Application.ProcessMessages; //For at få vist EditAntalAdresser.Text

--
Med venlig hilsen
Kurt Guldbæk

---

Kurt Guldbæk wrote:

[Snip - en hel masse oplysninger fra Kurt]

Som nævnt, er det lang tid(ca. 8 år) siden, jeg sidst har kigget på Paradox.

Nu fremgår det ikke 100% klart hvad og hvordan, du kopierer filerne.
Men hvis du har en tabel(-fil), f.eks Adresser.db, så skal du være opmærksom
på, at der bliver bygget en ekstra fil for hvert index.
Det vil sige, at du skal huske at kopiere Adresse.*.
Nuværende brugere af Paradox kan nok bidrage med detaljer, men det er noget
med .yx1 .pq1 eller lignende.
Prøv at lave en:
dir Ejendomme_Admin_Tbl.* , og se hvad der kommer frem.
Hvis du ikke får kopieret de tilhørende indexfiler, er fejlen simpelthen 'at
de ikke eksisterer' og ikke 'out of date'.
Du skal nok ikke forvente, at jeg kan hjælpe dig mere. Jeg kan ikke huske
detaljerne mere.

--
Med venlig hilsen
Stig Johansen

---

> > Vi bliver nok nødt til at få lidt flere oplysninger af Kurt.
> >
> > --
> > Med venlig hilsen
> > Stig Johansen
>
> Jeg vil prøve at konkretisere det lidt mere:
>
> Filstruktur:
> --Ejendomme
> |_Tbl Her kopieres de nye filer til
> |
> |_Admin
> | |__Tbl Her ligger kildefilerne
>

Hej Kurt

Hvad med at sende (zippet pr. mail) hele projektet, det ville alt andet lige
være lettere at hjælpe dig.

Men derudover, mener jeg at du burde glemme alt om at arbejde direkte i
tabellerne med TTabel, så vidt jeg kan se så er SQL oplagt til dit brug og
på langt sigt en løsning du bedre kan porte til en anden database.

mvh
Henry

---

"Henry" <henry@nomail.com> skrev i en meddelelse
news:40711a68$0$478$edfadb0f@dread14.news.tele.dk...
> Hvad med at sende (zippet pr. mail) hele projektet, det ville alt andet
lige
> være lettere at hjælpe dig.
>
> Men derudover, mener jeg at du burde glemme alt om at arbejde direkte i
> tabellerne med TTabel, så vidt jeg kan se så er SQL oplagt til dit brug og
> på langt sigt en løsning du bedre kan porte til en anden database.
>
> mvh
> Henry
>

Det bliver nok lidt voldsomt, med databaserne fylder det zippet over 100MB.
Uden db er der 6.4MB zippet.
Men måske er det nok med den form, hvor der er problemer?

Ok med at det nok er bedre med SQL; jeg har blot svært ved at få startet med
det og så er det jo nemt at falde tilbage til det man kender!
Men det er måske løsningen på sigt, så det er nok bare at få begyndt.
--
Med venlig hilsen
Kurt Guldbæk

---

> > Hvad med at sende (zippet pr. mail) hele projektet, det ville alt andet
> lige
> > være lettere at hjælpe dig.
> >
> > Men derudover, mener jeg at du burde glemme alt om at arbejde direkte i
> > tabellerne med TTabel, så vidt jeg kan se så er SQL oplagt til dit brug
og
> > på langt sigt en løsning du bedre kan porte til en anden database.
> >
> > mvh
> > Henry
> >
>
> Det bliver nok lidt voldsomt, med databaserne fylder det zippet over
100MB.
> Uden db er der 6.4MB zippet.
> Men måske er det nok med den form, hvor der er problemer?
Måske, men det udelukkende for at spare mig for tid, hvis du har det på en
ftp et sted er det ikke noget problem at downloade det selv om der er 100mb.

> Ok med at det nok er bedre med SQL; jeg har blot svært ved at få startet
med
> det og så er det jo nemt at falde tilbage til det man kender!
Ja det er jo også mange gange det man tjener penge på.

> Men det er måske løsningen på sigt, så det er nok bare at få begyndt.
Jeg lavede selv noget statistik for et par år siden, jeg havde en database
på 2GB!! Og performance var MSSQL overlegen, men der er andre vigtige
fordele ved at gå over på SQL servere, men det er nok noget Off Topic her.
Pointen er at 100mb er ikke noget problem og du kunne sikkert beholde det
hele i en eller to tabeller og alligevel få bedre performance end med den
metode du bruger.
Men det er lidt svært at vurdere, jeg har stadigvæk ikke helt forstået hvad
det er for en applikation du forsøger at udvikle.

mvh
Henry

---

"Henry" <henry@nomail.com> wrote in message
news:4071636c$0$444$edfadb0f@dread14.news.tele.dk...
......snip....
> Men det er lidt svært at vurdere, jeg har stadigvæk ikke helt forstået
hvad
> det er for en applikation du forsøger at udvikle.
>
> mvh
> Henry

På www.lokalarkiver.dk/vinderup er der nederst til venstre i menuen en dato.
Det er en link til en side med kort beskrivelse af projektet.
Projektet er helt på amatørbasis og er mit første i Delphi.

Mvh Kurt

---

Kurt Guldbæk wrote:

> På www.lokalarkiver.dk/vinderup er der nederst til venstre i menuen en
> dato. Det er en link til en side med kort beskrivelse af projektet.
> Projektet er helt på amatørbasis og er mit første i Delphi.

Nå, Kurt, du skrev tidligere:
> Ok med at det nok er bedre med SQL; jeg har blot svært ved at få startet
med
> det og så er det jo nemt at falde tilbage til det man kender!
> Men det er måske løsningen på sigt, så det er nok bare at få begyndt.

Efter at have set din beskrivelse, samt billeder, vil jeg da absolut
anbefale dig at 'konvertere til SQL'.
Det vil gøre livet *langt* lettere for dig.

Jeg vil godt hjælpe dig på vej, men først skal vi lige vide lidt mere om
hvilke værktøjer du har til rådighed m.v.

Kan du oplyse om:
Delphi version nr. + (std/pro/ent/arc)?
Skal programmet kun bruges af dig, eller skal det distribueres?
Må det koste penge? (database licenser osv)
Skal det kunne køre enkeltbruger eller flerbruger?
Hvor store mængder data snakker vi om? - Altså antal rækker, der skal søges
i?

Det kan godt være, det lyder af mange spørgsmål, men det er for at (måske)
kunne anbefale et databaseprodukt.

Jeg kan ikke se din databasebeskrivelse[1], men ud fra det du skriver, kunne
det umiddelbart pege på MSDE.
Baggrunden for MSDE er, at du tilsyneladende opererer med søgning i
memofelter, og det er stort set det værste man kan gøre på denne jord.

[1] Gider ikke starte min windowsmaskine for at læse en wordfil.

--
Med venlig hilsen
Stig Johansen

---

Jeg svarer lige på spørgsmålene i teksten.
---snip---
> Jeg vil godt hjælpe dig på vej, men først skal vi lige vide lidt mere om
> hvilke værktøjer du har til rådighed m.v.
Det vil jeg gerne sige jatak til!

> Kan du oplyse om:
> Delphi version nr. + (std/pro/ent/arc)?
Delphi5 PRO

> Skal programmet kun bruges af dig, eller skal det distribueres?
Det skal distribueres.

> Må det koste penge? (database licenser osv)
Det, som det koster må jeg selv betale, der er ingen kunder til at betale.
Dog vil jeg godt ofre noget på det, måske 1.000-3.000kr

> Skal det kunne køre enkeltbruger eller flerbruger?
Oprindeligt havde jeg tænkt på enkeltbruger, da det (måske) vil blive brugt
på flere arkiver, men på hver deres database!

> Hvor store mængder data snakker vi om? - Altså antal rækker, der skal
søges i?
jeg har måske ikke forstået spørgsmålet rigtigt, men søgningen af hensyn til
skærmdata (hvis man kan sige sådan) er kun på få (1-3) kolonner ad gangen.
Ved søgningen for dataudtræk til skærm/printer er der mange flere!

> Det kan godt være, det lyder af mange spørgsmål, men det er for at (måske)
> kunne anbefale et databaseprodukt.
>
> Jeg kan ikke se din databasebeskrivelse[1], men ud fra det du skriver,
kunne
> det umiddelbart pege på MSDE.
> Baggrunden for MSDE er, at du tilsyneladende opererer med søgning i
> memofelter, og det er stort set det værste man kan gøre på denne jord.
Det er ikke MSDE (MicroSoftDatabaseEngine?), men BDE fra Borland.
Ved memofelter henter jeg først teksten ud og søger derefter. Det går
udemærket!



> Med venlig hilsen
> Stig Johansen

Pga påsken og familiære begivenheder får jeg ikke lavet meget i de næste
dage, men jeg vil meget gerne vende tilbage senere!

Med venlig hilsen
Kurt Guldbæk



Jeg svarer lige på spørgsmålene i teksten.
---snip---
> Jeg vil godt hjælpe dig på vej, men først skal vi lige vide lidt mere om
> hvilke værktøjer du har til rådighed m.v.
Det vil jeg gerne sige jatak til!

> Kan du oplyse om:
> Delphi version nr. + (std/pro/ent/arc)?
Delphi5 PRO

> Skal programmet kun bruges af dig, eller skal det distribueres?
Det skal distribueres.

> Må det koste penge? (database licenser osv)
Det, som det koster må jeg selv betale, der er ingen kunder til at betale.
Dog vil jeg godt ofre noget på det, måske 1.000-3.000kr

> Skal det kunne køre enkeltbruger eller flerbruger?
Oprindeligt havde jeg tænkt på enkeltbruger, da det (måske) vil blive brugt
på flere arkiver, men på hver deres database!

> Hvor store mængder data snakker vi om? - Altså antal rækker, der skal
søges i?
jeg har måske ikke forstået spørgsmålet rigtigt, men søgningen af hensyn til
skærmdata (hvis man kan sige sådan) er kun på få (1-3) kolonner ad gangen.
Ved søgningen for dataudtræk til skærm/printer er der mange flere!

> Det kan godt være, det lyder af mange spørgsmål, men det er for at (måske)
> kunne anbefale et databaseprodukt.
>
> Jeg kan ikke se din databasebeskrivelse[1], men ud fra det du skriver,
kunne
> det umiddelbart pege på MSDE.
> Baggrunden for MSDE er, at du tilsyneladende opererer med søgning i
> memofelter, og det er stort set det værste man kan gøre på denne jord.
Det er ikke MSDE (MicroSoftDatabaseEngine?), men BDE fra Borland.
Ved memofelter henter jeg først teksten ud og søger derefter. Det går
udemærket!



> Med venlig hilsen
> Stig Johansen

Pga påsken og familiære begivenheder får jeg ikke lavet meget i de næste
dage, men jeg vil meget gerne vende tilbage senere!

Med venlig hilsen
Kurt Guldbæk

---

Kurt Guldbæk wrote:

> Jeg svarer lige på spørgsmålene i teksten.

Ditto .. uha, påske .. gæster i går .. prøver alligevel.

>> Skal programmet kun bruges af dig, eller skal det distribueres?
> Det skal distribueres.

Ok.

>
>> Må det koste penge? (database licenser osv)
> Det, som det koster må jeg selv betale, der er ingen kunder til at betale.
> Dog vil jeg godt ofre noget på det, måske 1.000-3.000kr

Det var også min fornemmelse, kan jeg opfatte det som en slags
'velgørenhedsarbejde'?

> Det er ikke MSDE (MicroSoftDatabaseEngine?), men BDE fra Borland.
> Ved memofelter henter jeg først teksten ud og søger derefter. Det går
> udemærket!

Den misforstod du lidt, jeg er fuldstændig med på, at du p.t. bruger
BDE/Paradox, og at det p.t. går fint med memofelterne.
Det var bare lidt uklart(for mig) om du havde gang i en(stor) landsdækkende
løsning, eller om der var tale om(små) decentrale systemer.
MSDE *kunne* være et bud, men jeg ved ikke om den er gratis.

> Pga påsken og familiære begivenheder får jeg ikke lavet meget i de næste
> dage, men jeg vil meget gerne vende tilbage senere!

Jeg tror, der sidder mange tålmodige folk herinde, der er parat til at
hjælpe.

Men først skal vi lige finde ud af hvor vi skal hen.
Det er ikke særligt hensigtsmæssigt at bruge BDE/paradox, da det er et
'discontinued' produkt. Det betyder, at der ikke bliver videreudviklet på
det, og man kan derfor allerede betragte det som 'gammeldags'.

Jeg tror at det, på sigt, er interbase, der er den bedste løsning, for dig
og din fremtidige 'kundemasse', men det finder vi nok ud af.


--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <aaa@bbb.com> skrev i en meddelelse
news:c5ajub$2gr$1@sunsite.dk...

-----Snip-----
> > Det, som det koster må jeg selv betale, der er ingen kunder til at
betale.
> > Dog vil jeg godt ofre noget på det, måske 1.000-3.000kr
> Det var også min fornemmelse, kan jeg opfatte det som en slags
> 'velgørenhedsarbejde'?
Ja, det kan man godt sige. Dog har jeg selv stor interesse i det, jeg bruger
meget tid i foreningen.
-----Snip-----
> Det var bare lidt uklart(for mig) om du havde gang i en(stor)
landsdækkende
> løsning, eller om der var tale om(små) decentrale systemer.
Da vi ikke har et landsdækkende netværk at køre på er det decentrale
enheder.
> MSDE *kunne* være et bud, men jeg ved ikke om den er gratis.
Jeg går ud fra at MSDE er MicroSoftDatabaseEngine! Den kender jeg ikke noget
til, men det er vel en 'bror' til BDE!
-----Snip-----
> Men først skal vi lige finde ud af hvor vi skal hen.
Hvad mener du med det?
> Det er ikke særligt hensigtsmæssigt at bruge BDE/paradox, da det er et
> 'discontinued' produkt. Det betyder, at der ikke bliver videreudviklet på
> det, og man kan derfor allerede betragte det som 'gammeldags'.
Men de ting, der er lavet bliver jo da ved med at virke!
-----Snip-----
> Jeg tror at det, på sigt, er interbase, der er den bedste løsning, for dig
> og din fremtidige 'kundemasse', men det finder vi nok ud af.
Den skulle vel egentlig være med i Delphi 5?

Kunne vi etablere en direkte linie? Jeg tror ikke, at vor videre dispus har
interesse for ret mange! Min adresse i disse mail er OK [og ikke en snyder
som din ].

Med venlig hilsen
Kurt Guldbæk

---

Kurt Guldbæk wrote:

[snip - en masse om databaser]

Lad os opsummere dine muligheder:
1) BDE/Paradox (nuværende)
2) MSDE
3) Interbase (eller Firebird)
4) Flashfiler (nævnt af dig)

Som er BDE/Paradox 'deprecated', hvilket betyder, at der ikke bliver
arbejdet videre på disse. Umiddelbart er det ikke et problem, da det virker
p.t. Problemet kan opstå, hvis det pludselig ikke virker med kommende
versioner af windows, da der *ikke* vil komme en servicepack til BDE.

Jeg har nævnt MSDE, da det vistnok er gratis. MSDE er i virkeligheden en
full blown MS SQLServer, der er droslet ned. Det betyder, at den
funktionelt kan alt, men til gengæld kræver det en hel del af PC'en.
Den er også lidt langhåret at installere (mht. sikkerhed).
Det bedste komponentsæt til denne er ADO, men hvis jeg husker rigtigt, så
findes den ikke i Delphi 5/PRO(?).

Firebird er også nævnt. Firebird er en Open Source version af Interbase 6.0,
og er gratis. Problemet med Firebird er, om du kan få en fornuftig adgang
til den (=finde et fornuftigt komponentsæt).

Interbase nævner jeg, da den følger med Delphi. Jeg er dog ikke klar over,
om man har lov til at videredistribuere den. Her skal du nok have fat i
licensbetingelserne. Hvis man ikke har lov, kommer det til at koste penge.

Flashfiler har jeg aldrig brugt, og kan derfor ikke udtale mig.

Indtil videre har vi snakket database valg, og jeg vil foreslå dig at søge
videre hjælp ovre i dk.edb.database.

> Kunne vi etablere en direkte linie?

Helst ikke. Ikke for at være uhøflig, men jeg er nogle gange ude hos kunder
i ugevis, og har ikke mulighed for at svare direkte.

> Jeg tror ikke, at vor videre dispus har interesse for ret mange!

Det håber jeg da. Måske ikke *indholdet* at dit projekt, men det
*programmeringsmæssige* burde interessere mange.

> Min adresse i disse mail er OK

Pas på med det.

> [og ikke en snyder som din ].

Det er for at undgå sådan nogle som swen-virusen. Den høstede netop adresser
fra usenet.

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <aaa@bbb.com> skrev i en meddelelse
news:c5if8c$6sk$1@sunsite.dk...

Det med databaserne vender jeg tilbage til.
....snip...
> > Min adresse i disse mail er OK
> Pas på med det.
> > [og ikke en snyder som din ].
> Det er for at undgå sådan nogle som swen-virusen. Den høstede netop
adresser
> fra usenet.
OK. Måske skulle jeg gøre ligeså!

> Med venlig hilsen
> Stig Johansen
--
Med venlig hilsen
Kurt Guldbæk

---

"Stig Johansen" <aaa@bbb.com> skrev i en meddelelse
news:c5ajub$2gr$1@sunsite.dk...

> Jeg tror at det, på sigt, er interbase, der er den bedste løsning, for dig
> og din fremtidige 'kundemasse', men det finder vi nok ud af.
>

Forøvrigt har jeg også FlashFiler2, den skulle også være udmærket, så vidt
jeg har forstået kræver den ikke nogen databaseengine!
Jeg har dog aldrig prøvet den.
--
Med venlig hilsen
Kurt Guldbæk

---

> .....snip....
> > Men det er lidt svært at vurdere, jeg har stadigvæk ikke helt forstået
> hvad
> > det er for en applikation du forsøger at udvikle.
> >
> > mvh
> > Henry
>
> På www.lokalarkiver.dk/vinderup er der nederst til venstre i menuen en
dato.
> Det er en link til en side med kort beskrivelse af projektet.
> Projektet er helt på amatørbasis og er mit første i Delphi.

Kurt, som Stig også siger peger på, du bør seriøst overveje at benytte SQL
istedet, det ligger lige til
højre benet.

mvh
Henry

---

> > > Men det er lidt svært at vurdere, jeg har stadigvæk ikke helt forstået
> > hvad
> > > det er for en applikation du forsøger at udvikle.
> > >
> > > mvh
> > > Henry
> >
> > På www.lokalarkiver.dk/vinderup er der nederst til venstre i menuen en
> dato.
> > Det er en link til en side med kort beskrivelse af projektet.
> > Projektet er helt på amatørbasis og er mit første i Delphi.
>
> Kurt, som Stig også siger peger på, du bør seriøst overveje at benytte SQL
> istedet, det ligger lige til
> højre benet.

PS, jeg glemte at skrive, der er i princippet ingen grund til at skifte væk
fra paradox, SQL virker fint mod paradox. Men da der jo ikke videre udvikles
eller ydes support på paradox ja så er jo noget man skal overveje når man
starter en ny applikation.
Jeg har selv mange applikationer med paradox og jeg ved at det på et
tidspunkt vil blive et krav/nødvendighed at jeg konverterer til noget andet,
sandsynligvis nok msde/mssql.

mvh
Henry

---

> > På www.lokalarkiver.dk/vinderup er der nederst til venstre i menuen en
> dato.
> > Det er en link til en side med kort beskrivelse af projektet.
> > Projektet er helt på amatørbasis og er mit første i Delphi.
>
> Kurt, som Stig også siger peger på, du bør seriøst overveje at benytte SQL
> istedet, det ligger lige til
> højre benet.
>
> mvh
> Henry

Jer er helt indstillet på at gå over til SQL og har da også læst det jeg
umiddelbart kunne komme over om emnet. Jeg har læst Delphi5's kapitel om det
flere gange, men ikke fået særlig meget ud af det. Det lyder så
selvfølgeligt. når man læser det men i praksis kniber det!
Desuden har jeg ved søgning brugt SQL og også forsøgt at bruge det til
indsætning af nye data. Der sidste gik det galt, så der skal der læres nyt!

Med venlig hilsen
Kurt Guldbæk

---

Jeg har mødt 'Index is out of date' endnu engang et andet sted i programmet,
men måske er jeg der ved at komme problemet lidt nærmere.

I et forsøg på at omgå problemet med 'Out of date' har jeg valgt ikke at
lave nye detallierede tabeller ved udtræk fra de forskellige amtfiler. I
stedet har jeg med DatabaseDesktop samlet dem i store filer og bruger dem
til opslag via index.

Databasefiler:
1. Amter.db.
Felter:
AmtNr: A6 (burde måske være I eller S)
Amt: A30.
Intet sekundært index.

2. Kommuner.db.
Felter:
Amt: S
KommuneNr: I
KommuneNavn: A30.
Sekundært index:
1. Kommuner_Amt: Amt.
2. Kommuner_KommuneNr: KommuneNr.

3. Ejerlav.db
Felter:
KommuneNr: S
Ejerlav: I
EjerlavNavn: A50.
Sekundært index:
1. Ejerlav_EjerlavNR: EjerlavNr,
2. Ejerlav_KommuneNr: KommuneNr.

Desuden har jeg lavet en ny tom tabel:
4. MatrikelNr.db.
Felter:
Ejerlav : I
MatrikelNr : A5
Sekundæret index:
1. MatrikelNr_Ejerlav: Ejerlav.

Dette giver en kæde af 'Index-opslag', som foretages via TDBGrid.
Jeg vælger et amt, derefter en kommune og til sidst et ejerlav.
Efter valget af Ejerlav indskriver jeg et matrikelnummer i en editbox.
Derefter vil jeg gerne gemme ejerlav og matrikelnummer i MatrikelNr.db med
følgende procedure:

Procedure TOpretNyEjendom.ChkGemEjerlav;
Var Ejerlavnummer, Matrikelnummer : String;
Begin
Ejerlavnummer := tblEjerlav.FieldByName('EjerlavNr').Text;
Matrikelnummer := editMatrikelNr.Text;
With tblMatrikelNr do
Begin
If NOT
Locate('MatrikelNr',Matrikelnummer,[loCaseInsensitive,loPartialKey]) Then
Begin //Matrikelnummeret er IKKE fundet
tblMatrikelNr.Open;
if not (tblMatrikelNr.State in [dsInsert]) then tblMatrikelNr.Insert;
tblMatrikelNr.FieldByName('Ejerlav').Text := Ejerlavnummer;
tblMatrikelNr.FieldByName('MatrikelNr').Text := Matrikelnummer;
tblMatrikelNr.Post;
End;
End; // With tblMatrikelNr
End;

Dette giver følgende fejlmelding:
'Index is read only'.
Hvorfor er Index read only?

Så forsøger jeg følgende:

Procedure TOpretNyEjendom.ChkGemEjerlav;
Var Ejerlavnummer, Matrikelnummer : String;
Begin
Ejerlavnummer := tblEjerlav.FieldByName('EjerlavNr').Text;
Matrikelnummer := editMatrikelNr.Text;
With tblMatrikelNr do
Begin
If NOT
Locate('MatrikelNr',Matrikelnummer,[loCaseInsensitive,loPartialKey]) Then
Begin //Ejerlav fundet
tblMatrikelNr.MasterFields := ''; //tilføjet
tblMatrikelNr.IndexName := ''; //tilføjet
tblMatrikelNr.MasterSource.Destroy; //tilføjet
tblMatrikelNr.Open;
if not (tblMatrikelNr.State in [dsInsert]) then tblMatrikelNr.Insert;
tblMatrikelNr.FieldByName('Ejerlav').Text := Ejerlavnummer;
tblMatrikelNr.FieldByName('MatrikelNr').Text := Matrikelnummer;
tblMatrikelNr.Post;
tblMatrikelNr.MasterFields := 'EjerlavNr'; //tilføjet
tblMatrikelNr.IndexName := 'MatrikelNr_Ejerlav'; //tilføjet
tblMatrikelNr.MasterSource := dsEjerlav; //tilføjet
End;
End; // With tblMatrikelNr
End;

Nu bliver der skrevet i MatrikelNr.db og derefter kommer nu den kendte
fejlmelding:
Index is out of date. Index: MatrikelNr_Ejerlav.

Er der nogen logik i det?

--
Med venlig hilsen
Kurt Guldbæk

---

Hej Kurt

Hvis dit system har flere brugere, og databaseserveren bruges som
arbejdsstation, er det vigtigt at Local Share sættes lig True i BDEAdmin.

Men generelt, drop paradox, jeg har nogle få Paradox baserede systemer
tilbage hos mine kunder, -
der er tit et eller andet bøvl med korrupte index eller autoincrement felter
der pludselig holder op med at fungere.
Interbase er OK, specielt efter at maskinerne er blevet så hurtige, som de
er i dag.

mvh Thor

---

"Thor" <thor@thor.thor> wrote in message
news:c4scqk$2e3d$1@news.cybercity.dk...
> Hej Kurt
>
> Hvis dit system har flere brugere, og databaseserveren bruges som
> arbejdsstation, er det vigtigt at Local Share sættes lig True i BDEAdmin.
>
> Men generelt, drop paradox, jeg har nogle få Paradox baserede systemer
> tilbage hos mine kunder, -
> der er tit et eller andet bøvl med korrupte index eller autoincrement
felter
> der pludselig holder op med at fungere.
> Interbase er OK, specielt efter at maskinerne er blevet så hurtige, som de
> er i dag.
>
> mvh Thor
>

Der er kun een bruger, alt det med flerbrugere har jeg ikke lært endnu!
Mvh Kurt