I have a new table created in AREV and available in OI. The table contains 261999 records. The key being two parts Period_No*Order_No. Period_No is Btree Indexed. In Arev, SELECT tablename WITH PERIOD_NO=200605" returns 400 results in 5 seconds. The same select in OI TCL so far has not returned any results after 15 minutes. My network shows activity but only around 4%. Oengine shows processing but I can not click on EngineInfo and it appears to be not responding?

Any ideas? I will try restarting my computer.

John

John,

This rings a bell. For some reason too when we brought a table over from AREV to OI at one site the SELECT was veeerrry SLOW. I'm sure that you have tried rebuilding the index,etc. as we did.

I believe our work-around for this site was to remove the index in OI on that table and the select was much faster.

However, others may pipe-in and can explain this condition.

FWIW,

Ray Chan

Yes it appears like it is not using the index eventhough I rebuilt the index in OI. I will try taking it off and testing the select.

John

Removing the Index and doing the select took just as long. I added the index through OI and rebuilt and the select now works!

John

It may be that if the table is created in AREV and attached through OI, the .DBT may not initially contain the SI.MFS entry (and maybe not the bang file either.) I experienced this with my AREV tables when starting with OI; initially I had to recreate the indexes in OI through the DB Manager. Eventually my index maintenance tool got smart enough to maintain the .DBT too, and the problems abated.

DB Manager's semi-automatic approach to .DBT maintenance gets in the way by updating the .DBT when the table is first attached, then not updating when the index is created somewhere else.

Gerald

Cool.

I have yet to understand what advantages the DBT file offers!

We used it initially but had quite a few problems with DBT alignment, especially with deployed apps. We soon decided to leave the DBT static for SYS files but attach data files at logon. This is, of course, necessary for some users who switch between their client databases by detach/attaching the appropriate volumes. We've also disabled DBT updating with software updates.

It all works very quickly and reliably. Persuade me otherwise!

Richard,

I agree, however, the dbt file is necessary in the development mode as the correct tables need to be there whe the app opens. In our production systems the dbt files is very basic and contains no data files. The apps startup routine processes an ini file and attaches the necessary volumes (works great). The problem I had was the table was created in AREV then added to OI then the index was added in AREV. What was strange is OI saw the index and allowed me to initially rebuild it. But because I did not add the table with the Index to the Dbt file it was ignored when trying to select???

Anyway, if I had followed the rules and done everything in OI there would not have been a problem.

John

John

It's not necessary to include data tables in the dbt for development We just run the app with "Launch App" button and quit (takes about one second). That attaches the data tables for development.

I've done quite a lot of database management via Arev rather than OI but so far had no problems with indexes, etc. Maybe I've been lucky - although files have been small.

Perhaps I just found a "pinhole" in the dbt technology by doing things in a particular order.

Our app startup logic actually skips the attach if we are running on a dev copy. A long time ago we decided to use the dbt for development but for other reason skip it on the production systems.

John

John,

I have experienced exactly the same issues with indexes which could be rebuilt, but were not updated afterwards. I did not consider it to be a pinhole.

Gerald

I was trying to be kind. In fairness, if I had created the file and added the index in OI there wouldn't have been a problem.

View this thread on the Works forum...