Cannot rename Vendor - Field No. not defined

bfisher11

Hi,
I have a database on NAV 5.1 and SQL, which was upgraded from NAV 3.7 last year. We ran into an issue when trying to rename a vendor. During the rename process it goes through and looks like it is updating properly and then errors out saying, "Field No. 6200 is not defined in the Vendor table"

Field 6200 is not in a NAV 5.1 standard database. This field was in 3.7 called [Reverse Auction Participant]. Any ideas why it will not let me rename? Or where I can track this issue down?

Thank you,
Brent

garak

did you compile the objects after the upgrade from 3.7 to 5.01 :?:
There should the error displayed.

Now you can do the following (if you have the permissions):
1. Open your testdatabase to check if there is there also the error (it should so, because your testdatabase is a copy of your actuall DB)
2. start there (in your TestDB) the debugger and rename the Vendor. The debugger should stop on the position where the field is defined.
3. Or you mark all objects in your testdb -> compile it -> take a look to the marked only objects and check them.

David_Singleton

bfisher11 wrote:

Hi,
I have a database on NAV 5.1 and SQL, which was upgraded from NAV 3.7 last year. We ran into an issue when trying to rename a vendor. During the rename process it goes through and looks like it is updating properly and then errors out saying, "Field No. 6200 is not defined in the Vendor table"

Field 6200 is not in a NAV 5.1 standard database. This field was in 3.7 called [Reverse Auction Participant]. Any ideas why it will not let me rename? Or where I can track this issue down?

Thank you,
Brent

You should not be fixing this your self, it is an error made by who ever did the upgrade. Contact them and work with them to resolve it. Even if you fix the symptom, you need actually to fix the cause.

bfisher11

Hi David,
I am working with the client since we did the upgrade for them. I have never run across this before after an upgrade so I am trying to track it down.

Garak, yes the objects were compiled after the upgrade and we have been running for close to a year. We do have a test db and I had previously done those steps. The debugger does not actually show the entire rename process so it does not trace it to the actual cause. There are some objects that are not compiling right now but are unused and not licensed to, but I am walking through those to see if this may be the cause.

David_Singleton

Did you remove the "Part 1" codeunit form the upgrade process? It maybe one of the upgrade tools.

David_Singleton

Actually sorry its not going to be a codeunit. Some of the upgrades use temporary holding tables where they store values form fields that will be deleted. The most likely source is some table that is connected to the old 6200 field, that should have been deleted.

Open the old 3.70 database and see where that field links to in other tables.

bfisher11

Hi David,
We were able to search the old 3.7 database and found a table that was not deleted out in the upgrade process. Table 6242. We deleted that table and got it working. Thanks for the support.

Brent

David_Singleton

bfisher11 wrote:

Hi David,
We were able to search the old 3.7 database and found a table that was not deleted out in the upgrade process. Table 6242. We deleted that table and got it working. Thanks for the support.

Brent

:thumbsup: You are welcome.

Alex_Chow

bfisher11 wrote:

Hi David,
We were able to search the old 3.7 database and found a table that was not deleted out in the upgrade process. Table 6242. We deleted that table and got it working. Thanks for the support.

Brent

Fantastic!

David_Singleton

That was two years ago. but thanks.