I have a customer with a Windows 10 fileserver and 3x Windows 10 workstations.

The workstations access the fileserver via a shortcut which logs them directly into the database (The data is held on the fileserver).  The location of the data is specified as a mapped drive (K:).

They are now getting a "Table Name Already Exists" message when logging in, even when logging in on the fileserver using the master name and password (Which does not use a menu).

I realise that there was a similar problem posted some time ago, but no solution was suggested at the time.

The problem here is that the users don't use the same version of DataEase 8.5 (at some stage).

DataEase update the Status tables etc. on startup if there has been a change. In the last 8.5 there was a change to the status tables.

This works fine but if someone then "downgrade" the application with an older version of 8.5 then that normally works fine too, but they start fighting each other so after a while the change of the table will result in the problem you see.

The solution is to make sure that you run the same version of DataEase on all devices (this will be enforced in 8.6) and fix the RDRR manually i.e. HexEdit.

All 4 machines use the same version of DataEase (8.5.4.2674) - I installed it myself and have just logged in remotely to check that they all indicate 8.5.1.2674.

The fileserver originally had an older version of DataEase installed (8.5.1.2222 I think) but I installed the later version over the top of it.  There was no user database on the fileserver at this stage.

There are two databases on the fileserver.  The data itself is a result of migrating two V6.52 databases using the Migration tool in 8.5.4.2674.  Both databases were accessible without error messages when installed (And, I think, for a few days afterwards).  The Historic database is only accessible via the fileserver and one other machine - Accessing it from either machine is clean (No error message).  The main database, in daily use, gives the "Table Name Already Exists" message on all 4 machines.

Could you please tell me exactly which file needs amending (And where it can be found if it is buried in a maze of Windows sub-folders) and what needs to be amended - Thanks.

The problem is due to DataEase fighting over the status table version. To fix this in 8.5 we have removed the update of status reports in 8.5.5 which is available for download in the download centre.

it will not fix the problem if it has already occurred but it will prevent it from happening again when fixed.

http://www.dataease.com/static/files/DataEaseFull-8.5.5.2674.exe

I see this problem with one of my customer as well.

It will help, if you could let us know how to fix it ?

You have to fix it manually as the problem is that there is two entries in the RDRR for the same table.

It is caused by the Status Table update fighting.

The last version of 8.5 i.e. 8.5.5.2764 has a fix that will prevent it from happening/happening again after its fixed but the fix has to be done in hexedit.

The problem table is normally DQL Info. i.e $DeStat_DQLInfo$

he 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.

In the RDRR file that I sent to you the code in front of the $DeStat_DQLInfo$ name is 0C - What does that mean and might it solve my customer's problem if I set it to 0E?

Hi Peter.

If it was just that simple ;-)

0C is 1100 bin
0E is 1110 bin
0F is 1111 bin
In this context it is the last bit that is important.

Bit 0 1 = Record deleted

Bit 1 1 = Record modified since last backup

Bit 2 1 = Record added since last backup

Bit 3 1 = Record changed (added, modified, or deleted) since last backup

So 0C and 0E means the same. 

So the problem is when there are two entries in RDR which both has the same table name and is active.

When DataEase then try to update a table it will rename the first entry and then try to create a new entry with the correct name. Because there is two the second entry will stop DataEase from creating the new entry because the table it is trying to create already exist.

So the fix is then to set the last entry in RDR for the file to 0F so it is marked deleted.

PS! Just had idea. As DataEase will create the table if it doesn't exist you can just mark the table 0f, save the RDR and try to open the app again. Use the last 8.5.5.2674 we published the other day.

I will try that and let you know, but it may be some time before I am able to do so.

Just a suggestion for DataEase.....

Rather than us fiddling with RDRR... file. It would be nice if you could build a tool and all we have to do, run the tool and pickup the correct RDRR file. Everything else will be done by that tool. 

Only because, there are lot of customer running 8.x.... not there yet into 8.6 :-)

Looking for table $DeStat_DQLInfo$ in Hex editor.

I only found ONE table with this name.

So, decided to change that table into 0F as suggested and it worked fine.

Hi DataEase I have the same problem but the file RDRRxAAA.DBM does not exist. How can I solve the problem. I receive the message "Table name already exists" when Dataease starts the DB.

Look for a file with extension .RDR

So, it will be something like this RDRRAAAA.RDR

Like Arul said.
RDRR change extension from .DBM to .RDR in 8.5 simply because there was no way in the code to force older versions of DFW not to try to open and run DE85 applications due to a flaw in the version logic.

By changing this extension we stopped older versions of DFW finding the application.