Looks like DataEase 8 is no better than Ffenics.  While adding a field to a from which defined a table. I could not save with the error message that the Table already existed.  Sure enough when I viewed the table tab there were two tables listed with the same name both would open to the same data set.  I was able to recreate the table saving with a different name.  When I tried to delete the table in forms I was allowed to delete but the same two names existed in the table tab.  When I tried to delete the table under the table tab another listing appeared,  tried again just to see what happened and another listing of the table was created. Now there are four of these tables that do not really exist Is there a way in DE8 to remove this non-existing tables.  At least I was able to fix this in Ffenics.

Hi David.

I don't know which one will be most insulted by that, DataEase or Ffenics ;-)

To be fair, this bug is originally a DataEase bug that has been there since the beginning of DFW at least. I don't have any experience with it in Ffenics, but it doesn't surprise me that it hasn't been fixed there either.

We fixed this problem some time ago, but it seems that there is some residual problem which we are currently investigating.

The original problem stem from how DataEase create a table and make sure of it's integrity which might be useful in avoiding getting it.

DataEase check integrity of Derivations etc. when you create them so you are for instance not allowed to write a derivation that reference a field that doesn't "yet" exist, you have to create the field first and then reference it etc.

However there is no such check when you delete a field, this you can do as much as you like. So lets say you delete a field in Customer that is referenced in Order. Everything is fine. You will get an error message in Order when you try to use it, but nothing will be corrupted. Let say this derivation is conditional, so then you don't even get a problem when you use the form if you don't trigger the condition.

Then you do something that trigger a table change in the Form when you save it.

What DataEase will then do is the following:
1. Rename original table to Temp Form XXX
2. Create RDRR entry for new file and then try to create the new table with all the changes.
3. If this fails due to constraints broken in derivation as described above, the table will not be created.
4. DataEase will give error message "Table Cannot be created due to etc" and you are in the bin.

The problem now would be that your original form, is pointing at a table that really don't exist and your working table and data is in Temp Form xxx.

Our fix make sure that the original table is renamed back to the original name and the new entry should be deleted and this would in theory work. However, and this is what we are currently investigating is why sometimes there is two entries in RDRR for the same table.

As we are no longer able to replicate the problem, and neither is any of our customers. Don't misunderstand, there is plenty of application that have the double table problem, but nobody can tell us how they got it when before it was easy to replicate ;-)

This lead us to believe that the problem is that the RDRR entry might be left over from the old bug, and the new fix just get into trouble because the entry is already there.

The problem is that the form/table can work for a long time with this problem there and it will only present when you try to change it because when DataEase rename the original table to Temp Form xxx and try to create the New RDRR entry, it will fail because it than find the left over one that doesn't point at a file.

As the RDRR is rather sensitive material, we can't just go around deleting stuff right left and centre either so we need to make sure we understand the problem (which nobody seem to have been able to fix for 20 years ;-) properly.

In DFW this still a "managable" problem, but in DataEase Distributor which uses the table create/change on an industrial style this is a much bigger headache. Humans "know" what they do, so wouldn't try to create things in the wrong order, but when we automate this it is harder to get things in the right order. For instance imagine adding 10 new fields to a table, that all cross reference each other. 

We could start nesting to see which field depends on which field etc, but it is a no-starter because what do you do if the field reference a field in a table that is not yet created?

The solution is more structural, we need to change the way DataEase create tables and effect changes. So what we will do in the future is to add all the tables and columns first, then add the restraints and derivations in a second "sweep" this way we insure that these problem never arises.

However, this won't help you today but I hope you got a better understanding of why and how this problem occurs.

The term fix is to simply patch the RDRR manually which might sound daunting, but in reality it is quite straight forward. Just make sure you have a full copy of the RDRR before you start.

1. Download HexEdit from http://www.hexedit.com/ if you don't already have it.
2. Open RDRRxAAA:DBM where X is the Database letter for your app (I Know you know, but I write this for others to enjoy too ;-)
3. Search for the table name in Question, you will most likely get many hits so might be smart to search from the bottom.
4. Two positions in front of the Table Name is the Status DWORD. If the table is deleted it will be 0F and if it is Active it will be 0E

When you have the problem you are describing you will find two occurrences of the table name with 0E in front of it. What you need to do is to change the 0E into a 0F on the LAST one of them i.e. the one furthest down the list (If you search from the bottom it will be the first one!).

If you want to check if it is the right one simply try to locate the file that is referenced just below the name in the RDRR here COPYAAAC.TDF, just ignore the .DBM as all the table files will have the same name with different extensions.

Make sure you don't insert or change the length of the file as this will corrupt it, you need to OVERWRITE!

Save the RDRR and test it.

You should now be in the clear!

You have to appreciate that we inherited a product with a list of bugs and shortcomings as long as the history of time. We had to take a holistic approach  and also a step back. A team many times bigger than hours has worked on fixing bugs in this product for over 15 years without seeming to make much headway. It would be no point for us to walk down the same path as we would certainly loose the battle.

What we did was to "leave" DFW alone and start adding complimentary functionality that could be used instead of the original to solve a problem. Our goal with DE8 is to allow the developer a way forward, where there before wasn't one but we can't start fixing all the stuff that should have worked over the last 20 years.

By doing this we have gotten a much better understanding of the product and can understand bugs (like this one) much better than we could before, and suddenly fixing things like this become easy when it before was impossible.

Understanding is everything, and we now believe that the problem has very much been that the developers of DataEase didn't understand the product or the problems it had, and if you don't understand it how can you fix it? 

Thanks for the Help.  I have a backup copy that does not have the issue and will start my revision over.  I do like DataEase 8 and look forward to continue promoting the product here in the USA.  I was just hoping that this bug that I have dealt with for years would be prevented or an easy fix.

Will be soon! We will take some weeks and clean up old sins soon, so they won't get in the way of the share joy which is the new DataEase8 ;-)

We did fix this once already in 8.x but it doesn't seem to fix it all the way. We both enabled deleting of tables in Catalogue and introduced proper rollback when it failed to save. As it seems, some customers still manage to get the problem which we will investigate further. The delete table fix struggle a little as it will delete any table, but for some reason it will not delete when there is two... ;-)

I just had this same problem when I deleted a field then tried to save.  One of my other fields was derived using this deleted field (oops!) and so couldn't save the modified form. This caused the duplicate table to be created.  Not sure if this helps you find at least 1 cause for this error and prevent it.

I've used the instructions here and hexedit for the 1st time and fixed my database without issue!  So if I can do it and not moan then anyone can ;)  Not eligant but it gets the job done! :)