Error checkin Object - 154E Source and Target mismatch

[ellendavis]

I have a developer that is getting the following error (Final source and target record counts do not match)when trying to check in a object - This is a custom object.
He is able to check in the object if no changes are made to the object. But any changes to the object he is getting the following error: Final source and target record counts do not match
for object P5543214 and table JDESPECTYPE_FDASPEC.
Even a minor one such as just adding a comment
I am not sure why this is happening.

Does anyone have any idea where to start looking.

We did do a get from PD and checked the object in thinking that the object is corrupt in DV.

thank you
Ellen Davis

ERP 8.9 SP24
Windows SQL
Citrix
Fat clients

 

[peterbruce]

Ellen,

I suspect that the spec file(s) on the developers fat client have been corrupted. Can the object be checked out, changed and checked in on a different fat client?

If it is corrupt spec files on the fat client, virtually the only (and safest) option is to re-install the fat client. I have copied spec files from another fat client, but it was for a specific set of circumstances and the spec files were copied from the same pathcode on a fat client that had just been installed.

 

[ellendavis]

We tried to check the object out on another workstation and make the same change and the same thing happened. This issue is very puzzling as it seems to be happening where ever we try to change this object.

I am thinking of rebuilding the object in DV to see if that helps. I am not sure but it is worth a try.

 

[peterbruce]

Elllen,

That is definitely a puzzling issue.

Rebuilding the custom application may be your best work around, but I would still be concerned about the DV specs on your deployment server. If the DV specs are corrupt on the deployment server, you may not be able to delete the object in order to rebuild it with the same name. So you may need to use a different object name, which has its own difficulties if this object is called by any other object.

I would also be wanting to check the specs in the other pathcodes as well, which is easier said than done.

What was the situation when this problem first appeared? When was the object last successfully checked in? Was it since the last time the object was promoted to PY? Was there anything unusual about the last successful check in?
Can you check out, add a comment, and check in using the PY pathcode/environment (this may require a temporary change to the OMW rules)?

 

[ellendavis]

We were able to get the program fixed. What we ended up doing is deleting the object from DV this removed the object from CO. Then checking out in DV and then doing an Advance get from PY. Made the change and then checked in the object into DV.

So, it looked like the specs were corrupted in CO.

Thank you
Ellen Davis