Error while creating the Unique Index of the Primary Key of an Item

Question

Hi all,
I have deployed a new item (CO_CONTRACTUNIT_PRODUCT) in my publication. The deploy appears to be successfull as the item can be seen in the repository through the Mobile Manager.
The problem occurs when i sync my local DB to get the item offline. While synchronizing, the following error appears, both in the sync window and the log file ol_sync.log.
"ERROR",POL-5130,"11/09/2010 11:43:52","table or view %s.%s not found:CO_CONTRACTUNIT_PRODUCT,CO_CONTRACTID,OD_PRODUCTID,CO_CONTRACTUNITID","DB_ROSHNI"
However, the debug file gives this other error regarding this table.
ALL_INDEX:CREATE UNIQUE INDEX "TPCO_CONTRACTUNIT_PRODUCT_PK" ON CO_CONTRACTUNIT_PRODUCT (CO_CONTRACTID,OD_PRODUCTID,CO_CONTRACTUNITID) -5130Error at C:\ADE\omeprod_ol103021\olite\db\build\win\ocapi\..\..\..\src\ocapi\allindexes.cpp line:329 rc:-5130
Build date Mar 29 2010
okErr=(table or view %s.%s not found)
mess=(CO_CONTRACTUNIT_PRODUCT,CO_CONTRACTID,OD_PRODUCTID,CO_CONTRACTUNITID)
AddLog(-5130 "ERROR",POL-5130,"11/09/2010 11:43:52","table or view %s.%s not found:CO_CONTRACTUNIT_PRODUCT,CO_CONTRACTID,OD_PRODUCTID,CO_CONTRACTUNITID","DB_ROSHNI")
But the index that is being created and is giving the error is the index created automatically with the Primary Key of the table, and so nothing has been modified in that.
The primary key of the table is created with the three columns that are part of the index that is returning the error.
As I could not solve the error, I tried to drop and re-create the item in the repository, but no luck. As a last option, i tried to remove the item from the repository to be able to sync properly again (just like before creating the item), but the error still happens.
Another weird point is that i have tried creating the item in another publication of another database (but with almost equal items), and the item could was downloaded to my local DB without any problem, which makes this problem still more bizarre.
What can it be?
Any help would be great!
Roshni

Answer 1

have you tried unistalling the client and reinstalling it?
schema evolution changes are not always handled correctly please check thread:
Modification of publication item into Mobile Server
i quote from rekounas instructions:
If you are just adding a field, you should only have to run the alter publication item API call.
Here is an old note on schema evolution on different scenarios. The names for the APIs that they use are now deprecated. Use the ConsolidatorManager class and call the method alterPublicationItem("PUBLICATION_ITEM_NAME", "SELECT STMT") :
A) Add column
1. Upload all client data. Clients should not add new data until they are told by the administrator to sync again!!
2. Stop Mobile Server listener
3. Change the Oracle8i/9i database schema (add column)
4. Create a Java program to call the Consolidator Admin API AlterPublicationItem()
5. Start Mobile Server
6. Execute a sync from the client
7. The new column should be seen on the client. Use MSQL to check snapshot definitions.
B) Drop column
1. Upload all client data. Clients should not add new data until they are told by the administrator to sync again!!
2. Stop Mobile Server listener
3. Delete column of the base table in the Oracle database schema
4. Create a Java program to call the Consolidator Admin API DropPublicationItem()
5. Create a Java program to call the Consolidator Admin API CreatePublicationItem() and AddPublicationItem().
6. Start Mobile Server
7. Execute a sync from the client
8. The new column should be seen on the cliet. Use MSQL to check snapshot definitions.
C) Change column datatype
Changing datatypes in a repliatated system is not an easy task. You have to follow certain procedures in order to make it to work. Use DropPublicationItem, CreatePublicationItem and AddPublicationItem methods from the Consolidator Admin API. You must stop/start Mobile Server listener to refresh the cache.
1. Client syncs. Clients should not add new data until they are told by the administrator to sync again!!
2. Stop Mobile Server listener
3. Drop/create column (do not use conversion procudures) at the base table
4. Call DropPublicationItem(). Check if the ErrorQueue and InQueue no longer exist.
5. Call CreatePublicationItem() and AddPublicationItem(). Check if the ErrorQueue and InQueue reflect the new column datatype
6. Start Mobile Server. This automatically resumes application
7. Client executes sync. This should drop the old snapshot and recreate the new snapshot. Use MSQL to check
snapshot definitions.
D) Drop table
1. Client syncs. Clients should not add new data until they are told by the administrator to sync again!!
2. Stop Mobile Server listener
3. Drop base table
4. Call DropPublicationItem(). Check if the ErrorQueue and InQueue no longer exist.
5. Start Mobile Server. This automatically resumes application
6. Client executes sync. This should drop the old snapshot. Use MSQL to check snapshot definitions.
E) Add table
1. Client syncs. Clients should not add new data until they are told by the administrator to sync again!!
2. Stop Mobile Server listener
3. Add new base table
4. Call CreatePublicationItem() and AddPublicationItem() method
5. Start Mobile Server. This automatically resumes application
6. Client executes sync. This should add the new snapshot. Use MSQL to check snapshot definitions.
F) Changing Primary Keys
Chaning PK is a severe operation which must be executed manually. A snapshot must be deleted and recreated to propagate the changes to the clients. This causes a full refresh on this snapshot.
1. Client syncs. Clients should not add new data until they are told by the administrator to sync again!!
2. Stop Mobile Server listener
3. Drop the snapshot using DropPublicationItem() method o
4. Alter the base table
5. Call CreatePublicationItem()and AddPublicationItem() methods for the altered table
6. Start Mobile Server. This automatically resumes application
7. Client executes sync. The old snapshot will be replaced by the new snapstot using a full refresh. Use MSQL to check snapshot definitions.
G) To Change a Table Weight =>
Follow the procedure below to change the Table Weight parameter. The table weight is used by the Mobile Server/Synchronization to determin the sequence in which client records are applied to the Oracle database.
1. Run MGP to apply any changes in the InQueue to the Oracle databse
2. Change table weight using SetTemplateItemMetadata() method
3. Add/change constraint on the the base table which reflects the change in table weight
4. Synchronize
gl m8