SDO_RELATE and 3D indexes

Hi,
The documentation I have been able to find is not very clear on this. It says that the only operator that can be used with a 3d index is SDO_FILTER. What will happen if you try and use SDO_RELATE? Will it just use SDO_FILTER? Should it return an error?
Thanks
Sam

Sam,
Currently 3D analysis is only done at the index level via minimum bounding volumes. Because SDO_FILTER only does a primary filter, meaning it uses only the infomation in the index, it is the only operator capable of doing 3D analysis. SDO_RELATE and other operators also do secondary filtering (on top of primary filtering) - which means the do actual geometry-to-geometry comparisons. Hence, once SDO_RELATE and all other operators start doing secondary filtering, after the primary filter has been performed, they will only do 2D geometry comparison - they may not return an error however. Hope this helps.
-Justin

Similar Messages

Help! Create Table with SDO_RELATE query ignores indexes!

Hi, I have a SQL statement like:
select ...
from a, b where sdo_relate(a.loc,b.loc,'querytype=join mask=anyinteract');
When I run this as is, it runs quickly, <10 seconds, and doing an expalin on it shows it is using the spatial indexes.
However if I try:
create table tabl as <select statement>
or
insert into tab1 <select statement>
then it takes over 30 minutes. Examining the trace file shows:
Rows Execution Plan
0 CREATE TABLE STATEMENT GOAL: CHOOSE
0 LOAD AS SELECT
0 NESTED LOOPS
0 TABLE ACCESS (FULL) OF 'AC1'
0 TABLE ACCESS (FULL) OF 'AC2'
I've tried using querytype=WINDOW, I've tried optimizer_mode=RULE and CHOOSE, but nothing forces these create/insert statements to work effectively!
Is this a bug, a documented limitation or is there something I'm missing?
On Oracle 8.1.7, tried on both Linux and Sun Solaris.
Thanks,
Andrew

Andrew,
This is a bug in the optimizer and extensible
indexing for Oracle 8i.
This is fixed in 9i.
Sorry, I don't have a better answer for
this problem.
null

What is the diffrence betweensy-tabix and sy-index

hi
can any one suggest me
what is the diffrence betweensy-tabix and sy-index
Thanks & Regards
kalyan.

Hi Kalyan,
This question has been answered many times on SCN. Please make a search before posting a thread.
Read the Rules of Engagement.
Happy Posting.
Regards,
Chandra Sekhar

ABAP-- diff between sy-sy-tabix and sy-index

Hi Guru's,
Pleae can anybody expalins me what is the difference between sy-tabix and sy-index(Loop Index) ?
Because in one case i am Modifyimg the internal table inside the do loop by giving sy-index ((Index of Internal Tables)(MODIFY scarr_tab INDEX sy-index FROM scarr_wa TRANSPORTING currcode. ) in the syntax and in other case inside loop statement i am modifyng same record by giving sy-tabix MODIFY scarr_tab INDEX sy-tabix FROM scarr_wa TRANSPORTING currcode.) in the syntax.
in both cases its working fine but i am not getting which one i have to use where to modify the internal table?
regards
SATYA

Hi Henry,
SY-INDEX is the value of the current iteration. It is applicable for the following programming constructs in ABAP -
DO...ENDDO.
WHILE...ENDWHILE.
SY-TABIX (TABle IndeX) is applicable to internal tables. If you scroll down in the link which Eddie has given, you will find a more detailed explanation for sy-tabix and which statements affect its value.
Regards,
Anand Mandalika.

Difference between sy-tabix and sy-index?

tell me about sy-tabix and sy-index?what is the difference between sy-tabix and sy-index?
Moderator Message: Please search before posting. Read the [Forum Rules Of Engagement |https://wiki.sdn.sap.com/wiki/display/HOME/RulesofEngagement] for further details.
Edited by: Suhas Saha on Jun 18, 2011 5:33 PM

HI,
Here is a brief description of difference between SY_TABIX and SY_INDEX and using them with several conditions.
SY-TABIX
Current line of an internal table. SY-TABIX is set by the statements below, but only for index tables. The field is either not set or is set to 0 for hashed tables.
APPEND sets SY-TABIX to the index of the last line of the table, that is, it contains the overall number of entries in the table.
COLLECT sets SY-TABIX to the index of the existing or inserted line in the table. If the table has the type HASHED TABLE, SY-TABIX is set to 0.
LOOP AT sets SY-TABIX to the index of the current line at the beginning of each loop lass. At the end of the loop, SY-TABIX is reset to the value that it had before entering the loop. It is set to 0 if the table has the type HASHED TABLE.
READ TABLE sets SY-TABIX to the index of the table line read. If you use a binary search, and the system does not find a line, SY-TABIX contains the total number of lines, or one more than the total number of lines. SY-INDEX is undefined if a linear search fails to return an entry.
SEARCH <itab> FOR sets SY-TABIX to the index of the table line in which the search string is found.
SY-INDEX
In a DO or WHILE loop, SY-INDEX contains the number of loop passes including the current pass.
Hope this helps.
Thank you,
Pavan.

Diff b/w btree and bitmap index ?

What is the difference between btree and bitmap index ?
which one to used and when.
how they are differ from each other.

you'd love to see
http://www.oracle.com/technology/pub/articles/sharma_indexes.html

What is the difference between "Invisible" (11g) and "virtual" index?

Hi
What is the difference between the "Invisible" index and "virtual" index?
Thanks
Balaji

Indexes can be visible or invisible. An invisible index is maintained by DML operations and cannot be used by the optimizer. Actually takes space, but is not to be used as part of a potential access path.
AFAIK, a virtual index is created by the tools used in SQL statement access path tuning to provide an alternative for the optimizer to test. It does not take any real space as it is a pure in memory definition.

Access path difference between Primary Key and Unique Index

Hi All,
Is there any specific way the oracle optimizer treats Primary key and Unique index differently?
Oracle Version
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
SQL> Sample test data for Normal Index
SQL> create table t_test_tab(col1 number, col2 number, col3 varchar2(12));
Table created.
SQL> create sequence seq_t_test_tab start with 1 increment by 1 ;
Sequence created.
SQL> insert into t_test_tab select seq_t_test_tab.nextval, round(dbms_random.value(1,999)) , 'B'||round(dbms_random.value(1,50))||'A' from dual connect by level < 100000;
99999 rows created.
SQL> commit;
Commit complete.
SQL> exec dbms_stats.gather_table_stats(USER_OWNER','T_TEST_TAB',cascade => true);
PL/SQL procedure successfully completed.
SQL> select col1 from t_test_tab;
99999 rows selected.
Execution Plan
Plan hash value: 1565504962
| Id | Operation         | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |            | 99999 |   488K|    74   (3)| 00:00:01 |
|   1 | TABLE ACCESS FULL| T_TEST_TAB | 99999 |   488K|    74   (3)| 00:00:01 |
Statistics
          1 recursive calls
          0 db block gets
       6915 consistent gets
        259 physical reads
          0 redo size
    1829388 bytes sent via SQL*Net to client
      73850 bytes received via SQL*Net from client
       6668 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
      99999 rows processed
SQL> create index idx_t_test_tab on t_test_tab(col1);
Index created.
SQL> exec dbms_stats.gather_table_stats('USER_OWNER','T_TEST_TAB',cascade => true);
PL/SQL procedure successfully completed.
SQL> select col1 from t_test_tab;
99999 rows selected.
Execution Plan
Plan hash value: 1565504962
| Id | Operation         | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |            | 99999 |   488K|    74   (3)| 00:00:01 |
|   1 | TABLE ACCESS FULL| T_TEST_TAB | 99999 |   488K|    74   (3)| 00:00:01 |
Statistics
          1 recursive calls
          0 db block gets
       6915 consistent gets
          0 physical reads
          0 redo size
    1829388 bytes sent via SQL*Net to client
      73850 bytes received via SQL*Net from client
       6668 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
      99999 rows processed
SQL> Sample test data when using Primary Key
SQL> create table t_test_tab1(col1 number, col2 number, col3 varchar2(12));
Table created.
SQL> create sequence seq_t_test_tab1 start with 1 increment by 1 ;
Sequence created.
SQL> insert into t_test_tab1 select seq_t_test_tab1.nextval, round(dbms_random.value(1,999)) , 'B'||round(dbms_random.value(1,50))||'A' from dual connect by level < 100000;
99999 rows created.
SQL> commit;
Commit complete.
SQL> exec dbms_stats.gather_table_stats('USER_OWNER','T_TEST_TAB1',cascade => true);
PL/SQL procedure successfully completed.
SQL> select col1 from t_test_tab1;
99999 rows selected.
Execution Plan
Plan hash value: 1727568366
| Id | Operation         | Name        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |             | 99999 |   488K|    74   (3)| 00:00:01 |
|   1 | TABLE ACCESS FULL| T_TEST_TAB1 | 99999 |   488K|    74   (3)| 00:00:01 |
Statistics
          1 recursive calls
          0 db block gets
       6915 consistent gets
          0 physical reads
          0 redo size
    1829388 bytes sent via SQL*Net to client
      73850 bytes received via SQL*Net from client
       6668 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
      99999 rows processed
SQL> alter table t_test_tab1 add constraint pk_t_test_tab1 primary key (col1);
Table altered.
SQL> exec dbms_stats.gather_table_stats('USER_OWNER','T_TEST_TAB1',cascade => true);
PL/SQL procedure successfully completed.
SQL> select col1 from t_test_tab1;
99999 rows selected.
Execution Plan
Plan hash value: 2995826579
| Id | Operation            | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT     |                | 99999 |   488K|    59   (2)| 00:00:01 |
|   1 | INDEX FAST FULL SCAN| PK_T_TEST_TAB1 | 99999 |   488K|    59   (2)| 00:00:01 |
Statistics
          1 recursive calls
          0 db block gets
       6867 consistent gets
          0 physical reads
          0 redo size
    1829388 bytes sent via SQL*Net to client
      73850 bytes received via SQL*Net from client
       6668 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
      99999 rows processed
SQL> If you see here the even though statistics were gathered,
     * In the 1st table T_TEST_TAB, the table is still using FULL table access after creation of index.
     * And in the 2nd table T_TEST_TAB1, table is using PRIMARY KEY as expected.
Any comments ??
Regards,
BPat

Thanks.
Yes, ignored the NOT NULL part.Did a test and now it is working as expected
SQL> create table t_test_tab(col1 number not null, col2 number, col3 varchar2(12));
Table created.
SQL>
create sequence seq_t_test_tab start with 1 increment by 1 ;SQL>
Sequence created.
SQL> insert into t_test_tab select seq_t_test_tab.nextval, round(dbms_random.value(1,999)) , 'B'||round(dbms_random.value(1,50))||'A' from dual connect by level < 100000;
99999 rows created.
SQL> commit;
Commit complete.
SQL> exec dbms_stats.gather_table_stats('GREP_OWNER','T_TEST_TAB',cascade => true);
PL/SQL procedure successfully completed.
SQL> set autotrace traceonly
SQL> select col1 from t_test_tab;
99999 rows selected.
Execution Plan
Plan hash value: 1565504962
| Id | Operation         | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |            | 99999 |   488K|    74   (3)| 00:00:01 |
|   1 | TABLE ACCESS FULL| T_TEST_TAB | 99999 |   488K|    74   (3)| 00:00:01 |
Statistics
          1 recursive calls
          0 db block gets
       6912 consistent gets
          0 physical reads
          0 redo size
    1829388 bytes sent via SQL*Net to client
      73850 bytes received via SQL*Net from client
       6668 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
      99999 rows processed
SQL> create index idx_t_test_tab on t_test_tab(col1);
Index created.
SQL> exec dbms_stats.gather_table_stats('GREP_OWNER','T_TEST_TAB',cascade => true);
PL/SQL procedure successfully completed.
SQL> select col1 from t_test_tab;
99999 rows selected.
Execution Plan
Plan hash value: 4115006285
| Id | Operation            | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT     |                | 99999 |   488K|    63   (2)| 00:00:01 |
|   1 | INDEX FAST FULL SCAN| IDX_T_TEST_TAB | 99999 |   488K|    63   (2)| 00:00:01 |
Statistics
          1 recursive calls
          0 db block gets
       6881 consistent gets
          0 physical reads
          0 redo size
    1829388 bytes sent via SQL*Net to client
      73850 bytes received via SQL*Net from client
       6668 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
      99999 rows processed
SQL>

Difference between primary key and primary index

Dear All,
Hi... .Could you pls tell me the difference between primary key and primary index.
Thanks...

Hi,
Primary Key : It is one which makes an entry of the field unique.No two distinct rows in a table can have the same value (or combination of values) in those columns.
Eg: first entry is 111, if you again enter value 111 , it doesnot allow 111 again. similarly for the strings or characters or numc etc. Remember that for char or numc or string 'NAME' is not equal to 'name'.
Primary Index: this is related to the performance .A database index is a data structure that improves the speed of operations in a table. Indices can be created using one or more columns, providing the basis for both rapid random lookups and efficient ordering of access to records. The disk space required to store the index is typically less than the storage of the table (since indices usually contain only the key-fields according to which the table is to be arranged, and excludes all the other details in the table), yielding the possibility to store indices into memory from tables that would not fit into it. In a relational database an index is a copy of part of a table. Some databases extend the power of indexing by allowing indices to be created on functions or expressions. For example, an index could be created on upper(last_name), which would only store the uppercase versions of the last_name field in the index.
In a database , we may have a large number of records. At the time of retrieving data from the database based on a condition , it is a burden to the db server. so whenever we create a primary key , a primary index is automatically created by the system.
If you want to maintain indices on other fields which are frequently used in where condition then you can create secondary indices.
Reward points if helpful.
Thanks,
Sirisha..

Difference between primary eindex and secondary index?

hi experts
pls answer me
difference between primary eindex and secondary index?
rewads apply.
thanks.
naresh.

hi,
check this link.
http://help.sap.com/saphelp_47x200/helpdata/en/cf/21eb2d446011d189700000e8322d00/frameset.htm
A difference is made between Primary & Secondary indexes to a table. the primary index consists of the key fields of the table and a pointer to the non-keys-fields of the table. The Primary index is generated automatically when a table is created and is created in the datebase as the same times as the table. It is also possible to define further indexes to a table in the ABAP/4 dictionary, which are then referred to as Secondary indexes.
Always it is not mandatory that an index should have all the key fields of a table. To see the index of a table
goto SE11->specify table name->click on the indexes... button on the application toolbar.
Based on your requirement you can you any of those index fields in the where clause of your query. Always its a better practice to use the index fields in the order specified. While selecting the records from a table it is always better to select the fields in the same order as specified in the table.

Difference between unique constraint and unique index

1. What is the difference between unique constraint and unique index when unique constraint is always indexed ? Which one is better in this case for better performance ?
2. Is Composite index of 3 columns x,y,z better
or having independent/ seperate indexes on 3 columns x,y,z is better for better performance ?
3. It has been very confusing for me to decide which columns to index, I have indexed most foreignkey columns, is it a good idea ? We do lot of selects and DMLS on most of our tables. Is there any query that I can run and find out if indexes are really being used and if they are improving any performance. I have analyzed and computed my indexes using ANALYZE index index_name validate structure and COMPUTE STATISTICS;
null

1. Unique index is part of unique constraint. Of course you can create standalone unique index. But is is no point to skip the logical view of business if you spend same effort to achive.
You create unique const. Oracle create the unique index for you. You may specify index characteristic in unique constraint.
2. Depends. You can't utilize the composite index if the searching condition is not whole or front part of the indexing key. You can't utilize your index if you query the table for y=2. That is.
3. As old words in database arena, Index may be good or bad for a table depending on the size of table, number of columns in the table... etc. It is very environmental dependent. In fact, It is part of database nomalization. Statistic is a way oracle use to determine the execution plan.
Steve
null

What's difference between ASC and DESC index

1 select count(*)
2* from big_emp e where hiredate >= to_date('1980-01-01', 'YYYY-MM-DD') and hiredate <= to_date('1983-12-31', 'YYYY-MM-DD')
COUNT(*)
11971
SQL> create index i_big_emp_hiredate on big_emp(hiredate);
Index created.
SQL> set autot trace
SQL> select empno, ename, hiredate
2 from big_emp e where hiredate >= to_date('1980-01-01', 'YYYY-MM-DD') and hiredate <= to_date('1983-12-31', 'YYYY-MM-DD') ;
11971 rows selected.
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 11766 | 218K| 19 |
|* 1 | TABLE ACCESS FULL| BIG_EMP | 11766 | 218K| 19 |
SQL> drop index i_big_emp_hiredate;
Index dropped.
SQL> create index i_big_emp_hiredate on big_emp(hiredate desc);
Index created.
SQL> select empno, ename, hiredate
2 from big_emp e where hiredate >= to_date('1980-01-01', 'YYYY-MM-DD') and hiredate <= to_date('1983-12-31', 'YYYY-MM-DD') ;
11971 rows selected.
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 29 | 551 | 4 |
| 1 | TABLE ACCESS BY INDEX ROWID| BIG_EMP | 29 | 551 | 4 |
|* 2 | INDEX RANGE SCAN | I_BIG_EMP_HIREDATE | 53 | | 2 |
i have 2 questions
1. In "Expert one-on-one Oracle", Tom said, there is no deference between ASC and DESC index in case of one column because Oracle can just read in reverse order. but my test made me confused. why Oracle did "full table scan" only in ASC index???
2. using "set autot trace" command. i believed the the "Rows" column mean the rows that Oracle access. Can you explain why the rows are 29(DESC) and 11766(ASC) in spite of the result is 11971. what is the exact meaning of "Rows" column in execution plan

I think what you're seeing is a bug in the optimizer. If you had printed up the predicate section of the execution plan, this would be more obvious. I have the query:
select *
from   t1
where d1 between to_date('01-jan-2001')
          and     to_date('31-dec-2003')
;This returns one row per day for 3 years, and when a normal index is created on it, the optimizer calculates the correct cardinality and uses a sensible set of predicates. But when I use a descending index, this is what I get:
Execution Plan
Plan hash value: 1429545322
| Id | Operation                   | Name | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT            |       | 1097 | 21940 |     2 |
|   1 | TABLE ACCESS BY INDEX ROWID| T1    | 1097 | 21940 |     2 |
|* 2 |   INDEX RANGE SCAN          | T1_I1 |     5 |       |     2 |
Predicate Information (identified by operation id):
   2 - access(SYS_OP_DESCEND("D1")>=HEXTORAW('8798F3E0FEF8FEFAFF') AND
              SYS_OP_DESCEND("D1")<=HEXTORAW('879AFEF8FEF8FEFAFF') )
       filter(SYS_OP_UNDESCEND(SYS_OP_DESCEND("D1"))>=TO_DATE('2001-01-0
              1 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
              SYS_OP_UNDESCEND(SYS_OP_DESCEND("D1"))<=TO_DATE('2003-12-31 00:00:00',
              'yyyy-mm-dd hh24:mi:ss'))Note the introduction of the strange sys_op_descend() function - which is related to the descending index implemention, and the extra FILTER predicates which introduce a significant extra selectivity effect. The optimizer is double-counting on selectivity effects, and introducing extra factors of 1% and 5% (I haven't checked exact details) due to the functions applied to columns and the range-based predicates.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

What is the difference between the drop and create the index and rebuild index ?

Hi All,
what is the difference between drop and create index & rebuild index ? i think both are same...Please clarify if both are same or any difference...
Thanks in Advance,
rup

Both are same. Rebuilding an index drops and re-creates the index.
Ref:
SSMS - https://technet.microsoft.com/en-us/library/ms187874(v=sql.105).aspx
TSQL - https://msdn.microsoft.com/en-us/library/ms188388.aspx
I would suggest you to also refer one of the best index maintenance script as below:
https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

What is Short Dump Analysis and secendry index ?

Dear Experts .
1.) What is purpose of T-codes SE30 and ST22 ?
What is Short Dump Analysis ?
2.) What is secendry index , How to use it ? How it effects the Performance of a report ?
Please it is urgent ...
Regards : Rajneesh

Hi
A dump analysis is a comprehensive list that should enable you to identify the causes and possible solutions of program errors. The ABAP Workbench generates a short dump whenever a report or transaction terminates due to a serious error. The system enters the error in the system log and writes a snapshot of the program at the moment when it terminated into a special database table called SNAP.
Dump analyses give the user or programmer information about the causes of the error that has caused the program to terminate. Experienced users can use them to identify very quickly where and why this occurred. He or she can them solve the problem.
The snapshot contains the following information:
Why the program has terminated
What caused the program termination
Where in the program code the termination occurred
What you can do to correct the error
The values of the relevant system fields when the program terminated
The calls or events that were active when the program terminated
Any other programs that are affected.
http://help.sap.com/saphelp_nw70/helpdata/en/c6/617d0ce68c11d2b2ab080009b43351/content.htm
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated

How can I have a default servlet and an index.html?

Hi,
I writing a small webapp to test/understand the 2.2 Servlet Spec. I am deploying this as a WAR to Orion, Tomcat and Silverstream.
The app's name is: "myapp"
My application has an index.html, which is listed as the sole welcome-file in the welcome-file-list element in the app's web.xml.
The interesting thing is that, after adding a default Servlet (<url-pattern>/</url-pattern>), I can no longer access the app's index.html either implicitly or explicitly:
1. Implicit:
- http://localhost/myapp
- http://localhost/myapp/
2. Explicit:
- http://localhost/myapp/index.html
- http://localhost/myapp/index.html/
All of these invoke the Default Servlet in all 3 app servers.
Question: How can I have both a default Servlet and an index page?
Thanks in advance.
Miles

you can define it in the web.xml file
look at the dtd, element "welcome-file-list"

SDO_RELATE and 3D indexes

Similar Messages

Maybe you are looking for