Recent

Author Topic: Index Oddity  (Read 10729 times)

Old Dog

  • New Member
  • *
  • Posts: 17
Index Oddity
« on: February 20, 2011, 10:24:58 pm »
I have a database of states with two indexes, abbreviation and name.  when the active index is abrev the records numbers are sequential.  when the active index is name the record numbers skip.  
Code: [Select]
procedure TFormStates.CreateStatesTable(AFileName : String);

begin
  With DbfStates do
    begin
      Close;
      with FieldDefs do
        begin
          Clear;
          Add('Abrev',ftString,2);
          Add('Name',ftString,25);
          Add('Country',ftString,6);
          Add('Neighbors',ftString,80);
        end;
      TableName:=aFileName;
      CreateTable;
      Exclusive := true;
      Open;
      AddIndex('ndxAbrev', 'Abrev', []);
      AddIndex('ndxName', 'Country + Name', []);
    end;
  MessageDlg('File created',mtWarning,[mbOK],0);
end;

I have tried regenerating the indexes, deleting the index file and re-adding  the indexes, and copying the data into a new file.  Same problem.

I will also create a bug report.
« Last Edit: February 21, 2011, 02:52:22 am by Old Dog »

sorinr

  • New Member
  • *
  • Posts: 19
Re: Index Oddity
« Reply #1 on: February 21, 2011, 02:28:16 pm »
Hi,

Can you be more specific on what kind of database do you use and in what circumstances do you use it.

From the code you have posted I presume u'r using dbf files.
Is your "name" index unique or one or many records can have the same value?

Regards.

Old Dog

  • New Member
  • *
  • Posts: 17
Re: Index Oddity
« Reply #2 on: February 21, 2011, 10:57:14 pm »
yes it is a dbf file created by this program.

the data is unique, there is only one state/province with a given name.

sorinr

  • New Member
  • *
  • Posts: 19
Re: Index Oddity
« Reply #3 on: February 22, 2011, 10:27:18 am »
Hi,

Are all your records in the country field exactly the same? Like "USA"? or some of them are "U.S.A" BECAUSE this is changing the composed index completely.
Or somewhere in the dbf data you have "nil" Country or Name fields.
« Last Edit: February 22, 2011, 10:30:55 am by sorinr »

Old Dog

  • New Member
  • *
  • Posts: 17
Re: Index Oddity
« Reply #4 on: February 24, 2011, 04:42:48 am »
All the same, either 'USA' or 'Canada'.  They are selected from combo box.

SteveF

  • Jr. Member
  • **
  • Posts: 92
Re: Index Oddity
« Reply #5 on: February 24, 2011, 06:32:35 pm »
I just want to clarify: when you use "abrev" as your index the record numbers are sequential, but when you use "name" the record numbers are not sequential?

You do realize that DBF files have this oddity: when an index is applied to a table, the records are automagically sorted by the field referenced by that index?  That in itself would explain the differing record number order.

Steve

Old Dog

  • New Member
  • *
  • Posts: 17
Re: Index Oddity
« Reply #6 on: February 27, 2011, 09:18:04 pm »
You miss understand.  I am not referring to the physical record number (Dbf.PhysicalRecNo) that the record has in the file, but to the virtual record number (Dbf.RecNo) that the record has, as an example, in a grid.  The data was not entered in order of either index.  There are 59 records.  When I use the abbreviation  index RecNo = {1,2,3,4,5,6,.....55,56,57,58,59}.  But when I use the name index RecNo = {1,2,3,4,5.....38,39,45,46,.....56,57,61,62....71,72,86,87,...}.  These number are not precise, but do illustrate the oddity.

sorinr

  • New Member
  • *
  • Posts: 19
Re: Index Oddity
« Reply #7 on: February 28, 2011, 07:19:04 am »
Yes, you are right. With no index the dbf.recno returns seqvential numbers from 1 to 59.
When you use the abrev index recno returns: 1,2,3.....,24,25,43,44....75,76
When you use the name index recno returns: 1,2...,19,20,25,26,...30,37,...

I will try to import the same data in a firebird table to see if the oddity persist when using zeos' s Ztable.
« Last Edit: February 28, 2011, 07:21:32 am by sorinr »

sorinr

  • New Member
  • *
  • Posts: 19
Re: Index Oddity
« Reply #8 on: February 28, 2011, 08:54:15 am »
Tested it with Zeos components on an FB table containing the same data and the oddity is gone.
The only explanation I think of is that TDbf.RecNo has a bug when using indexes.

SteveF

  • Jr. Member
  • **
  • Posts: 92
Re: Index Oddity
« Reply #9 on: February 28, 2011, 05:47:07 pm »
You miss understand.  I am not referring to the physical record number (Dbf.PhysicalRecNo) that the record has in the file, but to the virtual record number (Dbf.RecNo) that the record has, as an example, in a grid.  The data was not entered in order of either index.  There are 59 records.  When I use the abbreviation  index RecNo = {1,2,3,4,5,6,.....55,56,57,58,59}.  But when I use the name index RecNo = {1,2,3,4,5.....38,39,45,46,.....56,57,61,62....71,72,86,87,...}.  These number are not precise, but do illustrate the oddity.

As a non-Dbf user -- I strongly lean toward SQL databases in preference -- is there a reason this change is important?

In the SQL world, I would design the table to hold this data with three columns:
StateID (Numeric, Auto-Increment)
StateName (Text)
StateAbbrev (Text)

Then I don't have to worry about some administrative "record number" that may be arbitrarily assigned by the database engine -- I use the StateID number *held as data in my table* as the foreign key in the other tables that reference the State-data table.

Steve

Old Dog

  • New Member
  • *
  • Posts: 17
Re: Index Oddity
« Reply #10 on: March 04, 2011, 11:29:33 pm »
There are actually a few reasons the oddity is interfering with performance.  This is only one of several similar forms.  The other data bases have considerably more records.

1)  I had be using RecNo to navigate the table but came across MoveBy which will work in its place.

2)  I have a group of navigation buttons with differing jumps that I wanted to turn on and off depending on effectiveness.  For example a first button it useless when looking at the first record.

3)  I want to show record of total.  Not very useful if it says I am at record 67 of 59 records.  Assigning a record number to a record, even using auto increment, would only be useful when the records are in the order of entry, not when sort by some other criteria.

SteveF

  • Jr. Member
  • **
  • Posts: 92
Re: Index Oddity
« Reply #11 on: March 14, 2011, 05:30:44 pm »
There are actually a few reasons the oddity is interfering with performance.  This is only one of several similar forms.  The other data bases have considerably more records.

1)  I had be using RecNo to navigate the table but came across MoveBy which will work in its place.

2)  I have a group of navigation buttons with differing jumps that I wanted to turn on and off depending on effectiveness.  For example a first button it useless when looking at the first record.

3)  I want to show record of total.  Not very useful if it says I am at record 67 of 59 records.  Assigning a record number to a record, even using auto increment, would only be useful when the records are in the order of entry, not when sort by some other criteria.

As I've just been discovering, working on similar things, Lazarus has some built-in features that deal very nicely with items 2 & 3.

For item 2, use the TDBNavigator control.  If you want to have different jumps, take a look at this topic: http://delphi.about.com/od/usedbvcl/l/aa090203a.htm, which covers custom jumps among others.

For item 3:  The components I'm using for my data connection (ZEOSlib TZQuery) have the following properties:
RecordCount
RecNo

For the total record count, I execute a .Last on the query component & then ask for a .RecordCount.  For the current record (28 of...), grabbing the .RecNo in the TDBNavigator's Click event works quite well...

Steve

 

TinyPortal © 2005-2018