I have experienced when if I try to change a form and accidentally remove a field which is used by another field for a calculation I get the error message "Error in parsing derivation for field", which is fine but the problem I have is if I am saving the form under the same name I lose the table and all of its information. However I know that I can save the form/table under a new name but I don’t want to lose anything and I need to save the table with the same name .I cannot use a different name because I have a lot of Procedures and RelationShips that uses the table and I cannot restore the database from a saved copy because the DB is  updated by the final users. 

It’s a very old bug of DataEase and I think that it must be solved , but in the meantime there’s a solution that permit me to save the table with the same name?

This was and still is a DE problem since version 5.14

Hi Marco,

yes i think the same, this is a know problem since a long time. At first because of this and many other reasons SAVE and BACKUP

as many times as you can ! So my way to handle with, is if i have this kind of problem i take back my backup and clean out

all derivation or calculations of the field i want to delete. Yes i know it is not very elegant but in real i have not so often this kind 

of problem.

And at the second hand : Dit i understand it rigth that you make Progamchanges wihle other users are running in this applikation in
usermode ?

That's very brave, in my view!

I think this may cause many other problems......    :)

Kind regards

Markus

This problem occurs when a previously valid derivations suddenly become invalid.

DataEase derviations are compiled so they will be valid from the day they were compiled till DataEase try to recompile them. If a field it depend on has disappeared or a CDF is missing in the app etc. the derivation will no longer be valid and DataEase can no longer save the changes.

The way DataEase change a table is by renaming the old table, create a new table, then it transfers all the data to the new table and then it delete the old table (called Temp Form xx).

It is here it sometimes go wrong and it has to do with locking of the new table. 

It changes name on the Temp Form xx to the original name but sometimes it is not successful in deleting the new table with the same name.

One big reason for this happening is decimal separators in hard coded decimal numbers in derivations.

Before 7.2 this was read from windows but from 7.2 onwards this is fixed to . like all other programming tools as having a variable decimal separator in programming is "crazy". However for migrated applications this can be a source for this problem later on as the migration is done on binary level so it will not detect the problem immediately, but hen later on when you change the table it will baulk on the problem and not save the table.

It was fixed in 8.0 but it will need further fixing. The problem is old but the way it present changed in 8.0.

Before you would end up with the Temp Form xx and loose the table under the form. Now it keeps on working but you sometimes get a "ghost" table that does not interfere with the running of the app but cause problems when you try to change the table again.

THe problem when you try to change again is that after renaming the original table it can't create the new table because it already exist (the ghost).

The solution at the moment is either to save as new, delete all traces (both entries in Tables...you will see two table entries in the table list in catalogue) and then save back to the original name.

Alternatively use the Hexedit method described here.

We prefer the latter as it is more surgical and there has been reported problems with crossed wires in the app using method one.

http://www.dataease.com/DG3_ForumList/?ParentID=0000000521&field1=0000000521