Fix in 8 - Delete Table/Form directly in Catalogue (Ver. 8.0.0.1369)
A lot of "stubborn" problems have persisted in DFW for ages, some all the way back to Express.
One can ask if it is the bug that has been "stubborn", the developers that has been ignorant, or the management that has been bad...
Anyhow, we have now started a big program on fixing all these small "niggly" problems that all add up to big frustration and in many cases have been a big contributor when people have moved away from DFW (I am one of them...).
Always focusing on the "bigger picture" and arrogantly ignoring everyday problems for everyday users is the sure path to lack of confidence, customer happiness and finally falling sales and revenue.
When developing DE8 we have been hard and ignored all the "bugs" and concentrated on adding new and useful functionality to the product. Now we feel that we have added almost "too much" for the time being, and when we allow our users to catch up with the new functionality we will divert some resources into fixing old and "cherished" bugs.
We have already fixed a really bad (crazy) bug when one change a table. This bug resulted in the Form/Table link being lost and the new table existing in DataEase terms but not in physical terms...i.e. the file missing.
The data and original file is still there, but it is now called Temp Form xxx.
The only way one could link the table and the form up again was to first get rid of the existing/non-existing table. The "easy" way to do this is to hex edit the RDRR. Set the correct table name to deleted and then change Temp Form xxx to the correct name and start over.
Needless to say, most users aren't computer brain surgeons, so the only real way forward is to restore a backup if you have one.
Our first fix was to fix the "change table" routine so if it fails, the fail safe and reversal works as it should and as it was intended to work back in 1992...
The problem mostly occour when DE try to create the new table with changes and discover that a previously legal Derivation etc. has now become illegal (All derivations are re-parsed). This can be because a table has been deleted, a field been renamed or deleted etc.
When this happens, DataEase give an error message and bail out. Before the fix, it bailed out to misery...
When we changed the internal function GetGlobal()/SetGlobal() to GetVar()/SetVar() we had a lot of these problems, and before the fix it would have caused major "trauma".
We had one form where we used these functions in 14 different places. So with the old bug, we could have suffered complete disaster 14 times... But after the fix it was a breeze, and worked as it should all those years ago.
Lazy as we are when we discovered the problem: Derivation in Field CusotmerID is invalid! Can't save...
We fixed it in CustomerID and tried to save again... same problem now in a different field, we repeat the fix and save and repeat this 14 times.
Suddenly it saved and everything worked as it should.... Finally!
However we still have the problem with Temp Forms xxx in our apps. It can be because of historical problems, or because DE GPFed when you tried to save (still happens sometimes I'm afraid, but far from as regularly as you are used too...).
So the first thing you want to is to be able to delete any table for whatever reason you have (not the reason we think you should have...).
And that is what is now fixed.
You can now simply delete any table/form for whatever reason you want and it will be deleted if it exist, if it doesn't exist, if it believe it exist...GONE!
But there is one problem left before you can match up your backup table (Temp Form xxx) with the form, and that is to be able to rename the table, and that is being implemented as we speak.
Rename table can be very useful for other "hacks" too. You can for instance match up a form and a table that didn't originally belong together...
Lots of opportunities.