TRANSFERFIELDS - Really, really odd behaviour

NickA

Hi All,

So, I get a support call from a customer that's been running fine for ages, suddenly they start getting an error in TRANSFERFIELDS (Sales Line->Sales Shipment Line) because two fields have the same ID but different names and data types. Now, I've been a NAV developer for some time and I know what this means:-

The two fields below must have the same type:
Field: Load No. <-- Process Line
Table: Sales Shipment Line <-- Sales Line
Type: Integer <-- Boolean

Of course #-o why would anyone expect that to work, some idiot has created two completely different fields in these tables that as a general rule should ALWAYS be kept identical when it comes to the field definitions!

We've corrected the main problem by creating new field definitions and basically putting the tables back in line with each other, but what I don't understand is, no-one has modified the objects involved for 12 months, I've even gone to an old backup and compared objects, nothing has changed. Last week it worked, this week it doesn't. The fact that it should never have worked in the first place is kind of a moot point, because it has worked for at least 12 months like that.

Was there ever a time that transferfields was more forgiving under older versions of the client? Maybe it was ok in the past about mapping TRUE/FALSE to 0/-1 on integers once upon a time? Maybe it was ok until someone recompiled the Sales-Post codeunit at which point it decided not to play any more?

I'm really confused anyway, if anyone can shed any light on this I'd be very grateful.

tia

David_Singleton

Pretty simple.

Go to a posted document and see what it has been putting in those fields. you should be able to restore a back up from a few days earlier which will show what the values were in the sales order before posting.

NickA

Go to a posted document and see what it has been putting in those fields you should be able to restore a back up from a few days earlier which will show what the values were in the sales order before posting.

It actually does appear to contain the Load Nos., but there's other bespoke elsewhere that looks like it might populate the Load No. after the initial shipment posting.

Doesn't alter the fact that TRANSFERFIELDS isn't behaving the way I expect.

David_Singleton

Interesting. Navision does store Boolean as an integer in SQL, so I guess technically the fields are compatible, but it should give an error.

I do notice though that you are on 4.00sp2, which was probably the most bug ridden SQL version of Navision ever. So its quite possible that you just recently applied a hot fix and it fixed it.

In any case, I really would recommend moving to at least 4.00sp3 CU9 see waldo's magic blog for more details. www.waldo.be

NickA

I do notice though that you are on 4.00sp2

Close, but no cigar the customer is on 4sp3.

David_Singleton

NickA wrote:

I do notice though that you are on 4.00sp2

Close, but no cigar the customer is on 4sp3.

I must have been reading two threads at the same time and mixed them up.

Which build are you on? You want to be on at least build 26565. Take a look here to find what build no you are on.

http://wiki.dynamicsbook.com/index.php?title=Build_No

Also since you asked about versions, does this mean that you recently applied some hot fix?

matttrax

NickA wrote:

some idiot has created two completely different fields in these tables that as a general rule should ALWAYS be kept identical when it comes to the field definitions!

When I was starting out I didn't know what TRANSFERFIELDS was. I made a client unable to create new customers :oops:

But to your main topic. SOMETHING changed. From my experience if you can't find a code change in NAV, and you can't find a change to SQL, it is often a data change. I can't tell you how many times I've seen someone change a setup option / put in a wrong posting group / whatever ridiculousness you want to insert and then be shocked when the system behaves differently than it used to.

All it takes is one field to be changed and for that field to be involved in some conditional statement. Then it's off you go down the rabbit hole. In this case one branch might have done a TRANSFERFIELDS but was never executed. Then some setup option was changed, and instead of the code that transfers fields one by one the new branch was executed.

You could try doing a code coverage in an old backup and comparing it to the live system. They should be the roughly the same.

NickA

Build 23305.

Asking about versions was just clutching at straws: This isn't a customer I would normally deal with and none of my colleagues are admitting to doing anything to their system in recent memory. The idea that something compiled under a previous version might continue to run until someone recompiled it surfaced at one point but... nah, very unlikely.

As mattrax says though, *something* changed.

The problem was in Sales-Post, the usual TRANSFERFIELDS that takes place from Sales Line -> Sales Shipment Line - there's no avoiding that code.

It doesn't really matter though, the customer is back up and running and I don't think there's a simple answer to this one!