How to turn off RENAME confirmation message?

Hi NAV Experts,

Is there any trick you can use to turn off the “Do you want to rename the record?” confirmation message? I managed to do that in code when I call RENAME from another object but not when you’re working on a current Rec. Ideally I want to change a key field as if it were other non-key fields - not showing any record renaming confirmation.

Any suggestion would be much appreciated.


Do you mean as in globally turn it off or just for a specific record. If for a sepecific record, then just do it in code. If you mean globally, think carfully about why you would want to do this, it could be a very very dangerous thing if it were possible.

Hi David,

Yes, I only want to do that with records in one or two tables, not globally. Would you happen to have a code snippet that can get around the “Do you want to rename the record?” message? I couldn’t figure that out myself because OnRename() will be called every time a record RENAME happens.



There are a few ways to get around this. The easy shortcut is to put the code on the form, but I would never recomend doing this.

It depends a lot on how the users will interact with the rename, and why is it happening so often. Some more details on that would help.

IN general though I would either
a/ Create a new field, and put code in that field where the user can do the rename, that way they never call the trigger on rename, since they never validate the primary key field.
b/. Create a function in the table that you can then call from a control on the appropriate form.

A key decided is what the users need to see when they do the rename, and most important why?

Q: It depends a lot on how the users will interact with the rename, and why is it happening so often. Some more details on that would help.

A: Hi David, this happens often when:

  • The primary key is a composite key derived from values of other fields in the same record
  • There is no way to know what the value of the key before runtime
  • Lookup is required from other tables (meaning the primary key must also be a foreign key in other tables)

One realworld example would be the way Serial Shipping Container Code (SSCC) is implemented, the industry standard tracking number for use in supply chain management. This18-digit number has to be the primary key for tracking and consists of the following parts:

  1. Packaging Code (1 digit)
  2. EAN.UCC Company Prefix (7 digits)
  3. Serial Reference (9 digits)
  4. Checksum (1 digit)

When user runs a form and start a packing task, he always needs to select a Packaging Code (known only at runtime). The warehouse staff would not know whether he will use a Carton, Case, or Bag to pack the order until he sees the items. Serial Reference is not necessarily sequential like a number we could just grab from No. Series because the Serial Reference has to consist of an Sales Order No. and the count of each container. Finally checksum is always calculated and its value is unknown until you provide 1, 2, and 3. In our implementation, we also have a Job No. field as part of the primary key in order to allow a new Rec to be created & initialized first so the user has a chance to fill in the other 2 fields.

A second example would be a manifest (we have an SCM solution that uses 3 custom tables: Manifest, Shipment, and Package). A manifest is a way of grouping shipments for pickup/dispatch and is to be sent to the Shipping Agent (again it is only known at run time). The Manifest No. (primary key) is defined by a Ship-from Code (Pickup Location), Shipping Agent Code, and Shipment Date. A company could have 10 different shipments but wish to put them on 2 different manifests (5 shipments on each). Or they could also choose to put 10 shipments on one manifest. Why this undetermined? Beacause this is often a very last-minute decision depending on available Shipping Agents we could book at the time. If we don’t use Manifest No. as the key what else could we have used? Line No.? Entry No.? The last two could never provide meaningful lookup.


Remember that it should be requested “Do you wish to rename?”.

To many people accidentally rename records, thinking that its a SEARCH field.

Plus if they rename it, make sure the related tables using the same field as a reference are also updated.

Hi Scott,

It seems instead you have to rethink your solution, and consinder to change the tables, so these fields are not part of the primary key!

You could instead use some entry no. or similar to make the record unique.



I would assist Lennart in his point of view. If you assign a unique no. (primary key field, potentially from a no. series or a consecutive entry no.) and assign this no. to the order document(s) you could afterwards change/find out the no. of the Serial Shipping Container Code (SSCC) and have it as a an additional field in the table that is releated to document(s).

Hi Scott, I wll also re-itterate what Lennart and Joerg are saying. I have personally implemeneted Containier shipping systems for a handfull of clients, all with the same core requirement and very similar to what you are doing… In all the cases, I used a unique integer to identirfy the tracking of the containier, and then used the reference fields else where. You just set "Alternate Search field in the foreign fields properties, and you can then search on the unique integer or the compound search key, so that is not an issue.

Start this the other way. I.e. start on the basis of using a Unique integer as the primary key, and list the problems you have with that, and we will help you solve them.