Re: dbexport/dbimport problems

Having read Andy's and David's comments I would now suggest that the collective advice on DBIMPORT is:- DBIMPORT creates the table, loads the table and then creates the indexes. On some occasions this will result in improved performance and on others it will result in poorer performance. My reasons for this are:- 1. Not all tables span more than 1 disk. 2. Not all indexes become memory resident. 3. Not all parts of an application access the tables in the same way. I would suggest that we should all keep this in mind when advising customers on whether or not to use DBIMPORT. Actually what I am currently advising customers is that, if performance is expected to be an issue, they should know their applications intimately and consider the effect of different locations of the index on performance. They could even do tests during system integration testing to determine which of the possible indexing scenarios is appropriate for the different phases of the work. With that knowledge they should consider writing their own versions of DBEXPORT/DBIMPORT to recreate the table in the ideal format. And, from my experience, different tables in the same database may require different index locations for optimum performance. Malcolm Weallans Online Database Consultancy 2 Arkley Court Maidenhead Berks SL6 2YR Phone 0628-72154 Fax 0628-37463 CIX - onlinedbc