Importing tables with a modified primary key

DerekHuizer

I just have some questions about the order in which a .fob or .txt is imported. This is the case:

We decided to change the structure of a functionality we have build in the past. Therefore we had to change the primary key. In your own database this is not a problem, as long as you make sure the new primary key field is filled with unique values in case there are any records.

In our team everyone has its own database. When you want to import the objects with a modified key you'll get an SQL error message, saying that the key cannot be modified as the field doesn't exist. If you add the new field yourself and then import the object again, the error message isn't shown and everything is executed as it should have.

I think the error message has it's origin in the way NAV imports tables. I think NAV imports the keys first and then the fields, can anyone confirm this?

Second question, is there another way to work around the fact that you have to create the new field which is the primary key first and then import the modified table?

Thanks in advance.

P.s.:Tomorrow I will post the complete error message

SigGunn

Answers to second question:

1. Export the changed table uncompiled as fob, import, select replace all then ok, compile.
2. Export the changed table as text, import, compile (There will be no warning about changed objects)

I think the answer to question 1 relates to the fact you cannot add the new field to a key without saving the table first.

DerekHuizer

Thank you for your reply. This afternoon I wil try this solution with one of my colleagues hopefully it works.