Careful with those Captions!

On occasions I have needed a table that is similar to an existing table but with maybe some changes that I didn't want to have to make to the standard system (such as adding a field to the primary key).

One easy way to do this is to design the table you want to copy and use the File, Save As... menu option to save the table as a new table name and ID.

If you do this, make sure you change the Caption for the table to match the table name. Today I spent far too long investigating a problem with an error message telling me a record could not be inserted into table X since it already existed.

For some bizarre reason, the error was only being triggered when a commit was being called so there was some guesswork as to where the error was actually taking place. No matter what I tried it appeared that something really weird was going on. Eventually in a fit of frustration, I deleted the table in question and yet the error message still appeared.

The problem? Well the table had been created by copying another table and the caption had not been changed. As a result the error message was giving the wrong table name - causing great confusion.

Now here's a question for seasoned veterans. Does anyone know why the error was only appearing at the point of a commit or when all commits were removed after all other code in the transaction had executed? When you put a lock on a table, does NAV use SQL BEGIN TRANSACTION and then use COMMIT or ABORT if an error is thrown, or does it cache all transactions to the locked table and only send them to the database when the COMMIT is executed? I think I might do a little experiment and log the SQL commands to see what is going on. If this is the case then removing the LOCKTABLE command would have helped the debugger pinpoint my error.

Quick “Debugging” Tip

Sometimes I want to check something in a bit of code and I don't want to have to step through the debugger. Maybe I want to check the filters that are being applied to a table, maybe it's the value in a particular field. Here's a quick bit of code that you can use to check on a value and, if you're not happy with the value abort the process.

In my example, I wanted to check the table view that had been applied to a record variable. I want the program to stop at the point of my message (something the MESSAGE function doesn't do as NAV saves up messages for a convenient point in time.) I also want to be able to abort the execution in order to give me chance to fix something and try again (something you can't do when debugging with the debugger unless you kill the NAV application in a brutal way.)

Here's the code I put in:

IF NOT CONFIRM(g_JobLedgerEntry.GETVIEW) THEN

ERROR('');

Notice that I'm using the Silent Abort from Vjeko's blog. This will display a confirmation box with the details I am looking for. If I click No, the process aborts and rolls back, allowing me to change some values and run it again.

Debuggered

I don't know how it happened but I broke my debugger, but it's OK; I fixed it! After reading some posts on MIBUSO (or was it dynamics user?), it seems I am not the only person this has happened to. Thankfully, reading the forums also pointed me to the solution.

The symptoms of the problem are that the debugger for Dynamics NAV 5.0 (and earlier versions) launches but the code window is not displayed. On my machine this happened for version 5.0, version 4.0 SP3, 4.0 SP2, clean installs, you name it. The only thing I could do was close the debugger window, which caused the window to close and then be re-launched after a short pause (I figured this was because the program was getting to the next trigger. You can see similar behaviour if you close the debugger when it is working properly). I kept closing the window and eventually returned to NAV (giving me chance to turn the debugger off).

I logged this as a support issue with Microsoft but the suggestions they gave me (based upon previously solved incidents) didn't help. The premise of their suggestions was that the debugger and application communicate using TCP/IP and that something (most likely an anti-virus program or firewall client) was intercepting this communication and preventing the debugger from displaying the code.

After trying various options suggested by Microsoft, I finally got fed up and searched for the solution myself. I was quite surprised to find lots of people with the same problem - although there were a large number of postings from people that had either not found a solution or not updated their post. I think the best posting I found was on the dynamics user group (although I think the same solution was shown on MIBUSO).

For me the solution was to use Add/Remove programs from the control panel to remove a program called "Advanced Gateway Client". I don't remember installing this program and after I removed it the only difference I noticed was that my debugger worked again. Debuggered!