ddeditor and ADP SCH INFO table

I know that someone has warned in the past that ddeditor is full of bugs (I think it was Yuval...), but for me it is the only alternative since

I don't have access to the ddcomp utility (or may be I have it and don't know how to use it...) .

Anyway here is a situation: I have added few fields to the case table using an exported schema file.
Then I imported the file back using the apply changes procedure of the ddeditor (upgraded successfully) BUT - I couldn't see these fields in the ddeditor's object case form.
However - Using TOAD I've found out that the new fields actually exist in table case BUT they were not updated in ADP_SCH_INFO table (which should contain all DB fields) .

Moreover - navigating the case form and all its sub forms become very slow.

-make a backup of all you're going to change.
-take all the meta data info from production (relations,fields,indexes...), and put on your test adp
tables.
-Update adp_tbl_oid (next objid to assign), cause test an production maybe have different
number of rows, i use to launch this update:

update adp_tbl_oid set obj_num=3D(select max(objid)-268435456 from table_case)
where type_id=3D(select type_id from adp_tbl_name_map where type_name=3D"case")

1.We don't use a Flexible Deployment system in the test environment.
2.I've managed to find 2 *cfy files : prod.cfy (c:\clarify\efrontoffice\clarifyClient) and prod.cfy (c:\clarify\efrontoffice\ddeditor) - do you have any clue regarding their functionality?
is it safe to delete them?
3. Couldn't find any *.05x file.

This has happened to me in the past. Check the indexes on the case table. They are more than likely gone. One of the DDE bugs is that it drops the case table indexes and never re-builds them. This is most likely why your forms have become so slow.

Sounds like you have multiple issues here. First off, the *.cfy and *.05x
files can be deleted and will be rebuilt when you open the client or DDE
(just make sure you are out of the client before deleting them).

On indexes, the index on case objid was created when the database was
created. The case_index which is on the id_number is part of your schema.
However, there should be several other indexes on table_case that came from
other sources such as dbtune and any custom ones you've added for
performance. These index are not necessarily part of the meta data so
you'll have to look at the database level. If you need help with that,
please let me know. This is related to the bug that was previously
mentioned about DDE (dropping indexes and not rebuilding them).

Another concern is you can't see the new fields that you imported. Sounds
like they were added at the database level but not in the adp tables (that's
where DDE reads from). You can either manually add them to the meta data
(adp tables) or drop them at the database level and start over. Again, if
help is needed please let us know. I would however restart the DDE and
double check this before you do anything. Just a word of warning, if you
aren't completely familiar with the adp tables, get some help before trying
to manually add something.

You are right - the "indexes" tab is empty! Do you have any suggestion regarding how I can restore them?

I've been thinking about transferring the entire case table (schema + data ) from my production area to the test area using Oracle tools. The downside is that using this way I couldn't be 100% sure that everything was updated (since I won't use a Clarify tool)
Other then that, is there any simple way to do that?

Yes I know that.
I think it would be much more safe to use the index script instead of moving the entire table from production.
Anyway, I would do it with our DBA who is much more familier in this stuff.