Options

Cannot rename Vendor - Field No. not defined

bfisher11bfisher11 Member Posts: 7
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

Comments

  • Options
    garakgarak Member Posts: 3,263
    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.
    Do you make it right, it works too!
  • Options
    David_SingletonDavid_Singleton Member Posts: 5,479
    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.
    David Singleton
  • Options
    bfisher11bfisher11 Member Posts: 7
    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.
  • Options
    David_SingletonDavid_Singleton Member Posts: 5,479
    Did you remove the "Part 1" codeunit form the upgrade process? It maybe one of the upgrade tools.
    David Singleton
  • Options
    David_SingletonDavid_Singleton Member Posts: 5,479
    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.
    David Singleton
  • Options
    bfisher11bfisher11 Member Posts: 7
    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
  • Options
    David_SingletonDavid_Singleton Member Posts: 5,479
    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.
    David Singleton
  • Options
    Alex_ChowAlex_Chow Member Posts: 5,063
    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!
  • Options
    David_SingletonDavid_Singleton Member Posts: 5,479
    That was two years ago. :mrgreen: but thanks.
    David Singleton
Sign In or Register to comment.