BLOB size problems after ugrading to NAV 2009

GaryD

We've recently upgraded the NAV executable to NAV 2009 from 5.0. We're currently on build 29629. We're using SQL Server 2005 as the database. We now notice an issue, not all the time but quite often, that when we fob export from our Production system to our Test system or vice versa, that the blob sizes between the two do not match afterwards. We're still testing this so I won't guarantee it but it looks like if we do an F11 compile on the object in the "from" system after the export/import, that the blob size changes to match the object in the "to" system. We've built a versioning tool for NAV and this is what has alerted us to the issue. Since the upgrade a lot of times it now shows issues between the BLOB sizes even after we do the export/import.

We've also noticed that if we just go into Object Designer and just start hitting F11 on some objects that we see the BLOB size changes. I wouldn't expect this as the original object is already compiled.

Just wanted to know if anybody else is aware of this issue and if anything is being done about it.

Thanks!

KYDutchie

Gary,

the objects you compile in the "From" database, have those objects ever been compiled with the new 2009 client?
When you import the objects with a 2009 Client, even an FOB, the system automatically compiles these objects to create the object metadata. Since new features have been added to the 2009 C/AL, the object size will increase between a 5.0 and a 2009 client.

Hopes this helps,

Regards,

Willy

GaryD

Willy,
Interesting, I hadn't thought of that. We had not done a mass compile. And I'm not sure that if we do an F11 on an object if the same object ever gives is the same problem. I'll keep an eye out for that.

So any idea why an F11 gives different results than a CTRL-S or just closing the object and answering Yes to the save/compile dialog?

einsTeIn.NET

This has been an issue for several years, not just an NAV 2009 issue. Of course, you're right that 2009 will increase the object size by adding meta data. But in former versions there was also something weird. I never discovered what was the reason, but I can tell you what I have seen so far.

Different BLOB size (it is always about a multiple of 4KB, I think up to 80KB)

• direct on import to another database
• after importing to another database
• after re-compiling objects
• after re-compiling objects in another database
• when opening database from another computer

Maybe it belongs to the build no. or the operating system of the client. But the most important thing is that it doesn't have an impact on the functionality of your objects.

ara3n

The blob fields are encrypted so my guess could be that it encrypts them and compresses them which causes different size. They could also just generate garbage data just to make it harder for people who try to reverse engineer the fob files.

kriki

I wouldn't be alerted by the different sizes. Even in the older versions there could be differences in sizes. When (quick)-comparing objects between databases, I never considered BLOB-size as an indicator for different version between databases.

einsTeIn.NET

ara3n wrote:

... to make it harder for people who try to reverse engineer the fob files.

Thankfully from 2009 it isn't necessary to rebuild an export functionality because it's finally there. [-o<

GaryD

Thanks for the info people. I learned a thing or two.