[Delphi][dBase]Aangemaakte index not found

Pagina: 1
Acties:

  • Paul
  • Registratie: September 2000
  • Laatst online: 20:29
Ik heb momenteel een HEEL VAAG probleem.
Ik moet een applicatie maken die uit wat tabellen data ophaalt. So? What's the problem? Komt'ie :)

Door een hoop oude legacy werken we met dBase tabellen. Kun je in Delphi gewoon in een TTable gooien, dus geen probleem.
Nou heb ik echter een tabel, met indexen, waarvan hij iedere keer zijn indexen kwijt is.
Globale procedure aanmaken tabel:
code:
1
2
3
4
5
6
7
8
9
10
11
var Table : TTable;
begin
  Table := TTable.Create(Application);
  Table.FieldDefs.Add('SubscriberId',    ftInteger);
  [.. nog wat FieldDefs.Add ..]
  Table.FieldDefs.Add('StreetOverride',     ftString, 19);
  Table.IndexDefs.Add('IDNR',    'SubscriberId', []);
  Table.IndexDefs.Add('POSTCODE',   'PostalCode',   []);
  Table.IndexDefs.Add('TELEFOON',   'Phone',      []);
  Table.IndexDefs.Add('ACHTERNAAM', 'Surname',  []);
  Table.CreateTable;

Kan goed zijn dat ik wat dingen vergeet hierboven, maar het gaat dus om die IndexDefs.Add. Dit gaat bij 100 tabellen goed, maar hier niet... Bovenstaande komt hij overigens gewoon doorheen.

Dan doe ik in mijn applicatie:
code:
1
Table.IndexName := 'TELEFOON';

Exception: Index niet gevonden... Wtf :? Na wat gevogel heb ik dit bijgevoegd:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
  procedure irritanteIndexen(const naam, veld : string);
  begin
    try
    Table.IndexDefs.Find(naam);
    except
    Table.Active := false;
    try
      Table.DeleteIndex(naam);
    except
    end;
    try
      Table.AddIndex(naam, veld, []);
    except
    end;
    Table.Active := true;
    end;
  end;

begin
  Table := TableManager.GiveTable(TMCDFoonSubscriber);
  Table.Active := true;

  ShowMessage(IntToStr(table.IndexDefs.Count));
    for i := 0 to table.IndexDefs.Count - 1 do
    showMessage(table.IndexDefs.Items[i].Name);

  irritanteIndexen('IDNR',   'SubscriberID');
  irritanteIndexen('POSTCODE',   'PostalCode');
  irritanteIndexen('TELEFOON',   'Phone');
  irritanteIndexen('ACHTERNAAM', 'Surname');

  ShowMessage(IntToStr(table.IndexDefs.Count));
    for i := 0 to table.IndexDefs.Count - 1 do
    showMessage(table.IndexDefs.Items[i].Name);

  [..]
end;

Dit lijkt een vage opzet, zeker met die deleteindex erbij, maar anders gaat hij nota bene bij addIndex zeuren dat de index al bestaat |:(

Wat blijkt nou, de EERSTE keer dat ik irritanteIndexen aanroep, gaat hij zeiken dat de index niet bestaat. IEDERE keer dat ik de table opnieuw opvraag van de tablemanager. De andere indexen worden dan wel gevonden. De eerste keer die showmessages zijn er 0 (NUL) indexen :? Daarna (dus na 1x een index te hebben toegevoegd, de rest levert bij de Find geen exception op) zijn het er opeens WEL 4?
Als ik de volgorde waaron ik IrritanteIndexen aanroep verander, dan is het een andere index die niet gevonden kan worden, iedere keer de bovenste...

Weet iemand hoe ik dit in 's hemelsnaam op kan lossen? Want iedere keer dat je het nodig hebt wachten tot de addindex klaar is (5 minuten wachten dus, mits het idnr is, die duurt het korste) is natuurlijk niet te doen.

In honderd andere tabellen gaat het goed, kun je naar hartelust indexen gebruiken, maar hier niet. Dit zijn overigens wel de enige tabellen van enig formaat. De overige komen niet boven de 10k records uit, deze zijn resp enkele 100k, en 16m records groot (probleem speelt bij, tot dusver, 2 tabellen, en misschien nog 2, maar daar heb ik het nog niet op getest).
Ik heb al bijna 10 arbeidsuren besteed aan dit probleem, je kunt dus begrijpen dat mijn baas daar niet erg gelukkig van word.

Oh ja, ik heb gezocht. zowel op google als op Got, met de keywords dbase, index, fout, kapot, not found, delphi en zowat alle mogelijke combinaties.
Wel verrot dat bijna iedereen database afkort naar dbase :)

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock


Verwijderd

En als je de tabellen designtime aanmaakt?

Dat is ten eerste het makelijkste en ten tweede zie je ook gelijk of er iets fout is en wat de mogelijkheden zijn (in dit geval dus het aantal indexen).
Of je moet er natuurlijk een goede reden voor hebben, maar proberen kan nooit kwaad...

Ps: ik zie dat je een table create, fields aan toevoegd, maar nog geen tabel aan koppeld? Je moet natuurlijk wel eerst tabel aan koppelen voor je de index koppeld.

  • Paul
  • Registratie: September 2000
  • Laatst online: 20:29
Op woensdag 15 mei 2002 09:55 schreef @ndrewDynamo het volgende:
En als je de tabellen designtime aanmaakt?

Dat is ten eerste het makelijkste en ten tweede zie je ook gelijk of er iets fout is en wat de mogelijkheden zijn (in dit geval dus het aantal indexen).
Of je moet er natuurlijk een goede reden voor hebben, maar proberen kan nooit kwaad...

Ps: ik zie dat je een table create, fields aan toevoegd, maar nog geen tabel aan koppeld? Je moet natuurlijk wel eerst tabel aan koppelen voor je de index koppeld.
Ik zeg al, ik heb geen idee wat ik er allemaal vergeet. Dat wordt allemaal afgehandeld door de TTableManager die we gemaakt hebben. We zeggen gewoon Table := TableManager.GiveTable(tabelnummer);
Die tablemanager zorgt ervoor dat we tabellen krijgen als die al bestaan, en zo niet, maakt hij ze aan. We hebben ook geen TTable componenten op het form, de TableManager Create ze.

Zo werkt het bij 114 tabellen gewoon goed, en die worden op EXACT dezelfde manier gemaakt. Daarvan kun je wel gewoon de IndexName opgeven zonder foutmeldingen en zo.

Het frapante is ook, dat het steeds de EERSTE index is die het niet doet. De rest wel. Maakt niet uit of ik nou IDNR, TELEFOON, POSTCODE of ACHTERNAAM als eerste zet, de EESTE gaat fout, en de rest doet het gewoon

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock


Verwijderd

Altijd de eerste... Dat zijn altijd leuke "problemen". Dat lijkt erop dat of alles niet goed geinitialiseerd is, of een bug ergens anders in. Maar kun je iig proberen of die tabellen in designtime/handmatig wel goed gaat? Misschien andere versie van tabellen, kapotte tabel, etc.

  • Paul
  • Registratie: September 2000
  • Laatst online: 20:29
Op woensdag 15 mei 2002 10:50 schreef @ndrewDynamo het volgende:
Altijd de eerste... Dat zijn altijd leuke "problemen". Dat lijkt erop dat of alles niet goed geinitialiseerd is, of een bug ergens anders in. Maar kun je iig proberen of die tabellen in designtime/handmatig wel goed gaat? Misschien andere versie van tabellen, kapotte tabel, etc.
@designtime wil ik wel doen, maar dat kan vrijdag pas weer...

Dat het initialiseren fout gaat kan haast niet. Met exact dezelfde code maar een andere tabel gaat het wel goed nl.
Wel is hij 8 uur oid bezig geweest met het aanmaken van de tabel vauit een textbestandje... Iedere Post de indexen aanpassen, op het einde dus met minder dan een record per sec toevoegen... In het begin was dat 2k of zo :P

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock


Verwijderd

Dat wachten "we" tot vr'dag maar...

Wel wreed hoor, 8 uur bezig... Eenmalig neem ik aan?

Maar hij doet het dus wel, alleen gaat 1e keer fout? En het duurt dus lang. Even een tip: Als het nog vaak gebruikt wordt, waarom niet eenmalig converteren naar een andere tabel? Zie "database desktop" van delphi...

  • Varienaja
  • Registratie: Februari 2001
  • Laatst online: 14-06-2025

Varienaja

Wie dit leest is gek.

Ik kan je (nog) niet helpen, maar ik heb exact hetzelfde meegemaakt.
code:
1
2
3
4
5
6
7
8
   T2.IndexName:='IX_Shortcut';
   try
    T2.Active:=True;
   except
    T2.DeleteIndex('IX_Shortcut');
    T2.AddIndex('IX_Shortcut','Shortcut',[ixCaseInsensitive],'');
    T2.Active:=True;
   end; //BAH BAH BAH

Ik weet ook werkelijk niet wat ik eraan moet doen. Bij mij issie de index overigens alleen kwijt als er een insert of update geweest is.

*Zucht*... binnenkort maar weer ff wat uitproberen...

Siditamentis astuentis pactum.


  • Tomatoman
  • Registratie: November 2000
  • Laatst online: 22:33

Tomatoman

Fulltime prutser

dBase-bestanden bevatten nooit een index. De index wordt gemaakt in een apart bestand met dezelfde naam als de tabel, maar met een andere extensie. Wélke extensie weet ik niet uit mijn hoofd.

Kijk eens of je dat bestand met de indexdefinitie kunt vinden. Zo niet, dan is die index er waarschijnlijk ook niet.

Een goede grap mag vrienden kosten.


  • whoami
  • Registratie: December 2000
  • Laatst online: 22:05
Op woensdag 15 mei 2002 20:49 schreef tomatoman het volgende:
dBase-bestanden bevatten nooit een index. De index wordt gemaakt in een apart bestand met dezelfde naam als de tabel, maar met een andere extensie. Wélke extensie weet ik nu uit mijn hoofd.
Dat zou wel eens .idx kunnen zijn... Ben het niet zeker.

https://fgheysels.github.io/


  • Paul
  • Registratie: September 2000
  • Laatst online: 20:29
Op woensdag 15 mei 2002 20:49 schreef tomatoman het volgende:
dBase-bestanden bevatten nooit een index. De index wordt gemaakt in een apart bestand met dezelfde naam als de tabel, maar met een andere extensie. Wélke extensie weet ik niet uit mijn hoofd.

Kijk eens of je dat bestand met de indexdefinitie kunt vinden. Zo niet, dan is die index er waarschijnlijk ook niet.
Klopt... En dat bestand bestaat ook. Is zelfs van een fatsoenlijke grootte (lees: meer dan 200 mb op een database van 500)
Als het bestand niet bestaat of corrupt is, krijg je een heel andere melding, nl: Fout dit en dat, bestand [tabelnaam].mdx bestaat niet

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock


Verwijderd

DBF support in Delphi/BDE is doodgewoon veel te beperkt en niet betrouwbaar, vooral wanneer je met meerdere indexen werkt of met compound indexes.

Er zijn een aantal betere vervangers, zoals Apollo, Halcyon en Advantage TDataSet Descendant

Wij hebben ook nogal met legacy databases te maken, en zijn in die volgorde (Apollo, Halcyon, Advantage) aan de slag gegaan, en uiteindelijk bleek voor ons Advantage het betrouwbaarst te zijn.

Apollo bleek in staat te zijn om compound indexes te vernaggelen (vreemd, aangezien 't van de makers van SuccessWare komt, ooit een grote 3rd party ontwikkelaar voor Clipper), Halcyon had moeite met de 'deleted' flag in combinatie met indexes (pointers naar bookmarks raakten van slag wanneer de 'deleted' flag wijzigde), en Advantage werkt nog steeds rotsvast, zowel met FoxPro als met Clipper indexes.

Apollo en Halcyon zijn buyware, maar Advantage TDataSet Descendant staat nog steeds bij hun free downloads. :)
En ook al suggereren ze dat 'ie alleen maar werkt in combinatie met hun Advantage Server, dat is niet zo.
Pagina: 1