Professional Web Applications Themes

Type of indexes in DB2 - IBM DB2

Greetings, I would like to know what are the type of indexes supported in DB2. Is there any doentation that i could refer ? Does DB2 support Hash index ? I noticed, the CREATE INDEX gives 3 type of indexes, UNIQUE,CLUSTER and ALLOW REVERSE SCAN. How these indexes differ from each other ? Prompt feedback on this much appreciated Thanks Uthuras...

  1. #1

    Default Type of indexes in DB2

    Greetings,

    I would like to know what are the type of indexes supported in DB2. Is
    there any doentation that i could refer ? Does DB2 support Hash
    index ?

    I noticed, the CREATE INDEX gives 3 type of indexes, UNIQUE,CLUSTER
    and ALLOW
    REVERSE SCAN. How these indexes differ from each other ?

    Prompt feedback on this much appreciated

    Thanks

    Uthuras
    Uthuras Guest

  2. #2

    Default Re: Type of indexes in DB2

    "Uthuras" <uthurashotmail.com> wrote in message
    news:2ebe688f.0309120205.97b63e7posting.google.co m...
    > Greetings,
    >
    > I would like to know what are the type of indexes supported in DB2. Is
    > there any doentation that i could refer ? Does DB2 support Hash
    > index ?
    >
    > I noticed, the CREATE INDEX gives 3 type of indexes, UNIQUE,CLUSTER
    > and ALLOW
    > REVERSE SCAN. How these indexes differ from each other ?
    >
    > Prompt feedback on this much appreciated
    >
    > Thanks
    >
    > Uthuras
    These are not 3 different kinds of indexes. All three attributes can be
    defined for a single index.

    The unique clause specifies that each entry in the index only has one
    occurrence, such as employee_id in an employee table.

    Cluster defines the desired order of the rows in the table (the rows in all
    indexes are always in exact sequence). The clustering index is used to order
    the table rows during a reorg. It is also used (if defined) to determine
    where DB2 physically places a row when an INSERT for the table is used
    (unless the APPEND command has been defined on a table). Only one index can
    be defined as clustering since the sequence of the rows in the table can
    only be defined once. If no clustering index is defined, the index used to
    determined the order of the rows can be explicitly defined in the reorg
    command and all rows inserted into the table will be at the end of the
    table.

    Reverse scan is an option on an index that allow more efficient use of
    DESCENDING order sequence on an ORDER BY clause. Unless you have an SQL
    SELECT that uses sort by descending for a column that is in an index,
    probably not a good idea to use this clause.


    Mark A Guest

  3. #3

    Default Re: Type of indexes in DB2

    > > I would like to know what are the type of indexes supported in DB2. Is
    > > there any doentation that i could refer ? Does DB2 support Hash
    > > index ?
    > >
    There is no user defined option to define hash indexes. But DB2 does use
    hashing in the parallel versions (DB2 V7 EEE or DB2 V8 ESE) to partition the
    data (when partitioning of a tablespace is used).


    Mark A Guest

  4. #4

    Default Re: Type of indexes in DB2

    I'd say that there were type-1 indexes and now type-2 indexes. (type-1
    phasing/phased out)
    MDC tables have special attributes/indexes.

    <doc snip begin>
    Table and index organization for multi-dimensional clustering (MDC) tables
    is based on the same logical structures as standard table organization.
    When you create an MDC table, the following two kinds of indexes are created
    automatically:
    A dimension-block index, which contains pointers to each occupied block for
    a single dimension.
    A composite block index, which contains all dimension key columns. The
    composite block index is used to maintain clustering during insert and
    update activity.
    <doc snip end>


    [url]http://publib.boulder.ibm.com/infocenter/db2help/index.jsp[/url]
    Search : Using the CREATE INDEX statement
    Search : Index structure

    PM




    "Uthuras" <uthurashotmail.com> a écrit dans le message de
    news:2ebe688f.0309120205.97b63e7posting.google.co m...
    > Greetings,
    >
    > I would like to know what are the type of indexes supported in DB2. Is
    > there any doentation that i could refer ? Does DB2 support Hash
    > index ?
    >
    > I noticed, the CREATE INDEX gives 3 type of indexes, UNIQUE,CLUSTER
    > and ALLOW
    > REVERSE SCAN. How these indexes differ from each other ?
    >
    > Prompt feedback on this much appreciated
    >
    > Thanks
    >
    > Uthuras

    PM \(pm3iinc-nospam\) Guest

  5. #5

    Default Re: Type of indexes in DB2

    >
    > Reverse scan is an option on an index that allow more efficient use of
    > DESCENDING order sequence on an ORDER BY clause. Unless you have an SQL
    > SELECT that uses sort by descending for a column that is in an index,
    > probably not a good idea to use this clause.
    also
    SELECT MAX(COL1)
    will scan the whole index if it does not allow reverse scans
    AK Guest

  6. #6

    Default Re: Type of indexes in DB2



    Mark A wrote:
    > "Uthuras" <uthurashotmail.com> wrote in message
    > news:2ebe688f.0309120205.97b63e7posting.google.co m...
    > > Greetings,
    > >
    > > I would like to know what are the type of indexes supported in DB2. Is
    > > there any doentation that i could refer ? Does DB2 support Hash
    > > index ?
    > >
    > > I noticed, the CREATE INDEX gives 3 type of indexes, UNIQUE,CLUSTER
    > > and ALLOW
    > > REVERSE SCAN. How these indexes differ from each other ?
    > >
    > > Prompt feedback on this much appreciated
    > >
    > > Thanks
    > >
    > > Uthuras
    >
    > These are not 3 different kinds of indexes. All three attributes can be
    > defined for a single index.
    =========
    Exactly. They are attributes of DB2 UDB regular index. DB2 UDB use different
    approaches compare with some other DMBS system. For example, you can't directly
    define a BITMAP or a function index in DB2 UDB.
    =========

    >
    >
    > The unique clause specifies that each entry in the index only has one
    > occurrence, such as employee_id in an employee table.
    >
    > Cluster defines the desired order of the rows in the table (the rows in all
    > indexes are always in exact sequence). The clustering index is used to order
    > the table rows during a reorg. It is also used (if defined) to determine
    > where DB2 physically places a row when an INSERT for the table is used
    > (unless the APPEND command has been defined on a table). Only one index can
    > be defined as clustering since the sequence of the rows in the table can
    > only be defined once. If no clustering index is defined, the index used to
    > determined the order of the rows can be explicitly defined in the reorg
    > command and all rows inserted into the table will be at the end of the
    > table.
    >
    > Reverse scan is an option on an index that allow more efficient use of
    > DESCENDING order sequence on an ORDER BY clause. Unless you have an SQL
    > SELECT that uses sort by descending for a column that is in an index,
    > probably not a good idea to use this clause.
    Fan Ruo Xin Guest

  7. #7

    Default Re: Type of indexes in DB2

    Thanks for all your feedbacks. Really very much appreciated.

    what i want to know is how are ttheir index being implemented
    internally, as btree or as hash index?

    for example, for the 'unique' clause, is it implented as a btree with
    unique values, or is it a hash index?

    as for the cluster definition, does it relates a row with an adress
    space

    recerse scan is probably implemented as a btree index to make sorting
    works fast and efficient... but could you confirm that a btree is
    actually being implemented?
    Uthuras Guest

  8. #8

    Default Re: Type of indexes in DB2

    "Uthuras" <uthurashotmail.com> wrote in message
    news:2ebe688f.0309141948.682be501posting.google.c om...
    > Thanks for all your feedbacks. Really very much appreciated.
    >
    > what i want to know is how are ttheir index being implemented
    > internally, as btree or as hash index?
    >
    > for example, for the 'unique' clause, is it implented as a btree with
    > unique values, or is it a hash index?
    >
    > as for the cluster definition, does it relates a row with an adress
    > space
    >
    > recerse scan is probably implemented as a btree index to make sorting
    > works fast and efficient... but could you confirm that a btree is
    > actually being implemented?
    DB2 uses B-tree indexes. The one exception is on partitioning databases
    (parallel database in DB2 V7 EEE or DB2 V8 ESE) where DB2 also uses a
    hashing scheme on the partitioning key.

    There is always one (and only one) index row (with associated pointer to the
    table row) for each data row in the table. Index entries are always in the
    exact correct sequence. The pointer has information about the page (DB2 data
    is stored in 4K, 8K , etc pages) and row within the page. The index itself
    knows which table it belongs to.

    Not sure what you are asking about clustering. The clustering has no effect
    on the index structure. Clustering indexes are not any different than
    non-clustering indexes. The identification of the clustering index only
    determines what the desired order of the rows in the TABLE should be, during
    an insert of a row to the table, or during a reorg of the table. If the
    table rows are organized correctly in the clustering sequence defined (such
    as after a reorg), then DB2 might be more likely to use a clustering index
    than a non-clustering index, but the indexes themselves are not any
    different in how they work.



    Mark A Guest

  9. #9

    Default Re: Type of indexes in DB2

    > DB2 uses B-tree indexes. The one exception is on partitioning databases
    > (parallel database in DB2 V7 EEE or DB2 V8 ESE) where DB2 also uses a
    > hashing scheme on the partitioning key.
    >
    > There is always one (and only one) index row (with associated pointer to
    the
    > table row) for each data row in the table. Index entries are always in the
    > exact correct sequence. The pointer has information about the page (DB2
    data
    > is stored in 4K, 8K , etc pages) and row within the page. The index itself
    > knows which table it belongs to.
    >
    > Not sure what you are asking about clustering. The clustering has no
    effect
    > on the index structure. Clustering indexes are not any different than
    > non-clustering indexes. The identification of the clustering index only
    > determines what the desired order of the rows in the TABLE should be,
    during
    > an insert of a row to the table, or during a reorg of the table. If the
    > table rows are organized correctly in the clustering sequence defined
    (such
    > as after a reorg), then DB2 might be more likely to use a clustering index
    > than a non-clustering index, but the indexes themselves are not any
    > different in how they work.
    >
    Just to slightly qualify my remarks above. DB2 for OS/390 has an access
    method called "Direct Row Access" that might be the equivalent of hashing on
    other systems:

    From the manual:

    "If an application selects a row from a table that contains a ROWID column,
    the row ID value implicitly contains the location of the row. If you use
    that row ID value in the search condition of subsequent SELECTs, DELETEs, or
    UPDATEs, DB2 might be able to navigate directly to the row. This access
    method is called direct row access.

    Direct row access is very fast, because DB2 does not need to use the index
    or a table space scan to find the row. Direct row access can be used on any
    table that has a ROWID column.

    To use direct row access, you first select the values of a row into host
    variables. The value that is selected from the ROWID column contains the
    location of that row. Later, when you perform queries that access that row,
    you include the row ID value in the search condition. If DB2 determines that
    it can use direct row access, it uses the row ID value to navigate directly
    to the row."

    I have not been able to determine whether this exists on DB2 for Linux,
    Unix, and Windows.


    Mark A Guest

  10. #10

    Default Re: Type of indexes in DB2



    Mark A wrote:
    > > DB2 uses B-tree indexes. The one exception is on partitioning databases
    > > (parallel database in DB2 V7 EEE or DB2 V8 ESE) where DB2 also uses a
    > > hashing scheme on the partitioning key.
    > >
    > > There is always one (and only one) index row (with associated pointer to
    > the
    > > table row) for each data row in the table. Index entries are always in the
    > > exact correct sequence. The pointer has information about the page (DB2
    > data
    > > is stored in 4K, 8K , etc pages) and row within the page. The index itself
    > > knows which table it belongs to.
    > >
    > > Not sure what you are asking about clustering. The clustering has no
    > effect
    > > on the index structure. Clustering indexes are not any different than
    > > non-clustering indexes. The identification of the clustering index only
    > > determines what the desired order of the rows in the TABLE should be,
    > during
    > > an insert of a row to the table, or during a reorg of the table. If the
    > > table rows are organized correctly in the clustering sequence defined
    > (such
    > > as after a reorg), then DB2 might be more likely to use a clustering index
    > > than a non-clustering index, but the indexes themselves are not any
    > > different in how they work.
    > >
    > Just to slightly qualify my remarks above. DB2 for OS/390 has an access
    > method called "Direct Row Access" that might be the equivalent of hashing on
    > other systems:
    >
    > From the manual:
    >
    > "If an application selects a row from a table that contains a ROWID column,
    > the row ID value implicitly contains the location of the row. If you use
    > that row ID value in the search condition of subsequent SELECTs, DELETEs, or
    > UPDATEs, DB2 might be able to navigate directly to the row. This access
    > method is called direct row access.
    >
    > Direct row access is very fast, because DB2 does not need to use the index
    > or a table space scan to find the row. Direct row access can be used on any
    > table that has a ROWID column.
    >
    > To use direct row access, you first select the values of a row into host
    > variables. The value that is selected from the ROWID column contains the
    > location of that row. Later, when you perform queries that access that row,
    > you include the row ID value in the search condition. If DB2 determines that
    > it can use direct row access, it uses the row ID value to navigate directly
    > to the row."
    >
    > I have not been able to determine whether this exists on DB2 for Linux,
    > Unix, and Windows.
    DB2 UDB on LUW didn't give the user this choice. For those dbms who support this
    feature, such as ORACLE, INFORMIX, ..., they provide this way, but they don't
    recommend the customer use this way. When the database server upgrade, the
    customer need to take care of their applications if they used ROWID. And I guess
    if you need support both 32bit and 64bit applications, maybe the ROWID also
    cause the problem.




    Fan Ruo Xin Guest

  11. #11

    Default Re: Type of indexes in DB2

    > >
    > > From the manual:
    > >
    > > "If an application selects a row from a table that contains a ROWID
    column,
    > > the row ID value implicitly contains the location of the row. If you use
    > > that row ID value in the search condition of subsequent SELECTs,
    DELETEs, or
    > > UPDATEs, DB2 might be able to navigate directly to the row. This access
    > > method is called direct row access.
    > >
    > > Direct row access is very fast, because DB2 does not need to use the
    index
    > > or a table space scan to find the row. Direct row access can be used on
    any
    > > table that has a ROWID column.
    > >
    > > To use direct row access, you first select the values of a row into host
    > > variables. The value that is selected from the ROWID column contains the
    > > location of that row. Later, when you perform queries that access that
    row,
    > > you include the row ID value in the search condition. If DB2 determines
    that
    > > it can use direct row access, it uses the row ID value to navigate
    directly
    > > to the row."
    > >
    > > I have not been able to determine whether this exists on DB2 for Linux,
    > > Unix, and Windows.
    >
    > DB2 UDB on LUW didn't give the user this choice. For those dbms who
    support this
    > feature, such as ORACLE, INFORMIX, ..., they provide this way, but they
    don't
    > recommend the customer use this way. When the database server upgrade, the
    > customer need to take care of their applications if they used ROWID. And I
    guess
    > if you need support both 32bit and 64bit applications, maybe the ROWID
    also
    > cause the problem.
    >
    DB2 for OS/390 (which supports direct row access) doesn't give the user a
    choice either. DB2 decides which access method is best and will use direct
    row access only when DB2 thinks it will perform better. Using ROWID in a
    table does not guarantee direct row access.


    Mark A Guest

  12. #12

    Default Re: Type of indexes in DB2



    Mark A wrote:
    > > >
    > > > From the manual:
    > > >
    > > > "If an application selects a row from a table that contains a ROWID
    > column,
    > > > the row ID value implicitly contains the location of the row. If you use
    > > > that row ID value in the search condition of subsequent SELECTs,
    > DELETEs, or
    > > > UPDATEs, DB2 might be able to navigate directly to the row. This access
    > > > method is called direct row access.
    > > >
    > > > Direct row access is very fast, because DB2 does not need to use the
    > index
    > > > or a table space scan to find the row. Direct row access can be used on
    > any
    > > > table that has a ROWID column.
    > > >
    > > > To use direct row access, you first select the values of a row into host
    > > > variables. The value that is selected from the ROWID column contains the
    > > > location of that row. Later, when you perform queries that access that
    > row,
    > > > you include the row ID value in the search condition. If DB2 determines
    > that
    > > > it can use direct row access, it uses the row ID value to navigate
    > directly
    > > > to the row."
    > > >
    > > > I have not been able to determine whether this exists on DB2 for Linux,
    > > > Unix, and Windows.
    > >
    > > DB2 UDB on LUW didn't give the user this choice. For those dbms who
    > support this
    > > feature, such as ORACLE, INFORMIX, ..., they provide this way, but they
    > don't
    > > recommend the customer use this way. When the database server upgrade, the
    > > customer need to take care of their applications if they used ROWID. And I
    > guess
    > > if you need support both 32bit and 64bit applications, maybe the ROWID
    > also
    > > cause the problem.
    > >
    > DB2 for OS/390 (which supports direct row access) doesn't give the user a
    > choice either. DB2 decides which access method is best and will use direct
    > row access only when DB2 thinks it will perform better. Using ROWID in a
    > table does not guarantee direct row access.
    I want to know if you never define ROWID, will db2 for os/390 optimizer think of
    using this choice?


    Fan Ruo Xin Guest

  13. #13

    Default Re: Type of indexes in DB2

    "Fan Ruo Xin" <fanruoxsbcglobal.net> wrote in message
    news:3F6678DD.92D4F5E1sbcglobal.net...
    > > >
    > > DB2 for OS/390 (which supports direct row access) doesn't give the user
    a
    > > choice either. DB2 decides which access method is best and will use
    direct
    > > row access only when DB2 thinks it will perform better. Using ROWID in a
    > > table does not guarantee direct row access.
    >
    > I want to know if you never define ROWID, will db2 for os/390 optimizer
    think of
    > using this choice?
    >
    No, direct row access can only happen if a ROWID is defined on the table
    (and obviously in the where clause).


    Mark A Guest

  14. #14

    Default Re: Type of indexes in DB2

    "Mark A" <maswitchboard.net> wrote in message
    news:fRu9b.645$5f6.76723news.uswest.net...
    > "Fan Ruo Xin" <fanruoxsbcglobal.net> wrote in message
    > news:3F6678DD.92D4F5E1sbcglobal.net...
    > > > >
    > > > DB2 for OS/390 (which supports direct row access) doesn't give the
    user
    > a
    > > > choice either. DB2 decides which access method is best and will use
    > direct
    > > > row access only when DB2 thinks it will perform better. Using ROWID in
    a
    > > > table does not guarantee direct row access.
    > >
    > > I want to know if you never define ROWID, will db2 for os/390 optimizer
    > think of
    > > using this choice?
    > >
    > No, direct row access can only happen if a ROWID is defined on the table
    > (and obviously in the where clause).
    >
    Even if a ROWID is defined on a table and a unique index is defined on that
    column (with no other columns), DB2 will create (and sometimes use at its
    discretion) a regular B-Tree index (just like any other index).


    Mark A Guest

  15. #15

    Default Re: Type of indexes in DB2



    Mark A wrote:
    > "Fan Ruo Xin" <fanruoxsbcglobal.net> wrote in message
    > news:3F6678DD.92D4F5E1sbcglobal.net...
    > > > >
    > > > DB2 for OS/390 (which supports direct row access) doesn't give the user
    > a
    > > > choice either. DB2 decides which access method is best and will use
    > direct
    > > > row access only when DB2 thinks it will perform better. Using ROWID in a
    > > > table does not guarantee direct row access.
    > >
    > > I want to know if you never define ROWID, will db2 for os/390 optimizer
    > think of
    > > using this choice?
    > >
    > No, direct row access can only happen if a ROWID is defined on the table
    > (and obviously in the where clause).
    That is what I expected. I think the ROWID column will cause the problem in some
    cases, such as upgrading.
    In open system, almost all the dbms meet a problem - change some structure of
    the DMS layor from version to version. For example:
    -increase the tablespace size which allowed to use on one partition
    This means new version need more bit to save the tablespace#/container# than
    previous versions
    -tablespace partitioning, ...
    This means the container# in different tablespace partitions can use the same
    number. But all the containers are defined under the same tablespace.
    ....
    In this case, the customer need externally upgrade the ROWID column.


    Fan Ruo Xin Guest

  16. #16

    Default Re: Type of indexes in DB2



    Mark A wrote:
    >
    > >
    > Even if a ROWID is defined on a table and a unique index is defined on that
    > column (with no other columns), DB2 will create (and sometimes use at its
    > discretion) a regular B-Tree index (just like any other index).
    Can't think more now.
    I will think this tomorrow.

    Fan Ruo Xin Guest

  17. #17

    Default Re: Type of indexes in DB2

    > > > I want to know if you never define ROWID, will db2 for os/390
    optimizer
    > > think of
    > > > using this choice?
    > > >
    > > No, direct row access can only happen if a ROWID is defined on the table
    > > (and obviously in the where clause).
    >
    > That is what I expected. I think the ROWID column will cause the problem
    in some
    > cases, such as upgrading.
    > In open system, almost all the dbms meet a problem - change some structure
    of
    > the DMS layor from version to version. For example:
    > -increase the tablespace size which allowed to use on one partition
    > This means new version need more bit to save the tablespace#/container#
    than
    > previous versions
    > -tablespace partitioning, ...
    > This means the container# in different tablespace partitions can use the
    same
    > number. But all the containers are defined under the same tablespace.
    > ...
    > In this case, the customer need externally upgrade the ROWID column.
    >
    I am not sure why you think there will be a problem. The SQL statement does
    not depend on the existence of a ROWID column (other than it being a unique
    column). Even if direct row access ever disappeared, a simple rebind would
    resolve the problem.


    Mark A Guest

  18. #18

    Default Re: Type of indexes in DB2



    Mark A wrote:
    > > > > I want to know if you never define ROWID, will db2 for os/390
    > optimizer
    > > > think of
    > > > > using this choice?
    > > > >
    > > > No, direct row access can only happen if a ROWID is defined on the table
    > > > (and obviously in the where clause).
    > >
    > > That is what I expected. I think the ROWID column will cause the problem
    > in some
    > > cases, such as upgrading.
    > > In open system, almost all the dbms meet a problem - change some structure
    > of
    > > the DMS layor from version to version. For example:
    > > -increase the tablespace size which allowed to use on one partition
    > > This means new version need more bit to save the tablespace#/container#
    > than
    > > previous versions
    > > -tablespace partitioning, ...
    > > This means the container# in different tablespace partitions can use the
    > same
    > > number. But all the containers are defined under the same tablespace.
    > > ...
    > > In this case, the customer need externally upgrade the ROWID column.
    > >
    > I am not sure why you think there will be a problem. The SQL statement does
    > not depend on the existence of a ROWID column (other than it being a unique
    > column). Even if direct row access ever disappeared, a simple rebind would
    > resolve the problem.
    Yes. I agree!
    Any changing in the DMS layer or some other layers should guarantee this rule -
    the changing is transparent to the SQL interface or applications. The SQL
    queries and DML statements do not need to be modified or rewrited because of
    this changing. The SQL interface, or optimizer is very similar in both db2 and
    db2 udb for LUW. But DMS layer are much bound by the under level - operation
    systems.

    My point is the ROWID internal format maybe changed from one version to the next
    version. For example, the old format use 3 bytes for page number and 1 byte for
    slot number to save the ROWID; but new version want to use 8bytes to save this
    ID. During the upgrading, in most cases the migration utility will not take care
    of this. In worse case, the customer has to drop the table (which defined the
    ROWID column) and recreate the table in the new version and re-populate the
    data.



    Fan Ruo Xin Guest

  19. #19

    Default Re: Type of indexes in DB2



    Mark A wrote:
    > "Mark A" <maswitchboard.net> wrote in message
    > news:fRu9b.645$5f6.76723news.uswest.net...
    > > "Fan Ruo Xin" <fanruoxsbcglobal.net> wrote in message
    > > news:3F6678DD.92D4F5E1sbcglobal.net...
    > > > > >
    > > > > DB2 for OS/390 (which supports direct row access) doesn't give the
    > user
    > > a
    > > > > choice either. DB2 decides which access method is best and will use
    > > direct
    > > > > row access only when DB2 thinks it will perform better. Using ROWID in
    > a
    > > > > table does not guarantee direct row access.
    > > >
    > > > I want to know if you never define ROWID, will db2 for os/390 optimizer
    > > think of
    > > > using this choice?
    > > >
    > > No, direct row access can only happen if a ROWID is defined on the table
    > > (and obviously in the where clause).
    > >
    > Even if a ROWID is defined on a table and a unique index is defined on that
    > column (with no other columns), DB2 will create (and sometimes use at its
    > discretion) a regular B-Tree index (just like any other index).
    I know nothing about db2 for os/390. I ever discussed some questions with some
    people who support this kind of systems. Sometimes I found both sides based on
    the different assumption. Even the opinions from both sides make sense, but the
    conclusion is different.

    I am sorry I can't get the point what you mean here.
    In which scenario, the customer can be benefited from creating an index only on
    a ROWID column?
    That means the index entry will be like <ROWID, ROWID>. What does that suppose
    to mean?

    Fan Ruo Xin Guest

Similar Threads

  1. Multiple Indexes
    By Paul Seymour in forum Adobe Indesign Macintosh
    Replies: 11
    Last Post: September 29th, 07:04 PM
  2. indexes in cs
    By Albert_Constantineau@adobeforums.com in forum Adobe Indesign Macintosh
    Replies: 1
    Last Post: August 14th, 09:41 PM
  3. using indexes
    By tragik in forum Coldfusion Database Access
    Replies: 0
    Last Post: January 9th, 07:03 PM
  4. Indexes
    By tomL in forum Dreamweaver AppDev
    Replies: 2
    Last Post: March 14th, 04:26 PM
  5. Two indexes?
    By Andy_Fielding@adobeforums.com in forum Adobe Indesign Windows
    Replies: 1
    Last Post: August 14th, 02:55 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

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 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139