Navision Objects edited by an external Application

Bastiki

I need to edit the content of the documentation trigger outside of Navision. I read the object data using CFRONT, change it and store it back on the SQL-Server. Everything works fine as long as the length of a line or the length of the documentation trigger itself is not changed.
Does anybody know the structure of the FOB-Files (especially because of the stored checksum) or the object data in the database?

bbrown

What are you attempting to do? I would consider this to be a very bad idea. I think you run a real risk of corrupting objects. If you want to use an editor then export to text.

MTC

Bastiki wrote:

I need to edit the content of the documentation trigger outside of Navision. I read the object data using CFRONT, change it and store it back on the SQL-Server. Everything works fine as long as the length of a line or the length of the documentation trigger itself is not changed.
Does anybody know the structure of the FOB-Files (especially because of the stored checksum) or the object data in the database?

You cannot modify the fobs because of the checksum, NAV will not import them. You can change the data in the BLOBs of the Object table, but divulging information regarding this is more than my life is worth.

I can send you in the right direction however. Use something like UltraCompare to compare two exported BLOB fields in binary mode. Export an object's BLOB, change the documentation text to double its size, export again, then compare them. It isn't difficult to work out where NAV stores the offset and block length information. Also, it's always on a 4 byte boundary (text).

Good luck.

MTC

bbrown wrote:

What are you attempting to do? I would consider this to be a very bad idea. I think you run a real risk of corrupting objects. If you want to use an editor then export to text.

If he corrupts an object, it most likely will not run, or will definately crash the designer when you try to design the object. He's not messing around with any of the code, variable, or properties here. The documentation "trigger" is a simple text wrapper, and the easiest part of the BLOBs to reverse engineer.

MTC

In any case, I'm sure that Kine has done this before and there is a codeunit in the downloads section demonstrating this. Then again, I could have been dreaming.

EDIT: He's only reading the data out, not putting it back in, but his code should help you. You simply have to do the same thing in reverse.

http://www.mibuso.com/dlinfo.asp?FileID=343

Bastiki

I think u are talking about the report "developer documentation". This reports extracts the documentation from the blob field. I use the same technique in my application and i also know the issues concerning the checksum. I think that manipulating the blob is the best way. Objects exported as a textfile do not contain the documentation and the fob-files become easily unusable when editing within a binary editor.

I also tried to change one or more value within the doc-trigger but it seems to me as if navision does not always store every change in the right way.

I used a new clear codeunit. Removing 4 chars in a line in the doc-trigger decreases the values stored at offset 0x0134 and 0x0140 (blob saved to hdd) by 4. The value stored at 0x0000 changed too but in an unusual way. perhaps, this could be the checksum (?).

But when i add a function the position of the values are changed so that i can't rely on fixed positions nor on fixed range between the changed offset and the beginning of the trigger.

MTC

When you modify only the text within the document trigger of an object, only 3 long words of importance change their value along with the block where the text is. All three of these long words change by the same value, which is related to the length of the text within the documentation trigger.

A) Long word at offset 0, which relates to the length of the entire BLOB will need to be changed.

If you can extract text from the documentation, you know where the block for it starts. Now, these can move, but before where the documentation block starts there are two other long words, the first is what you need to get a lock onto, the second is 12 bytes later. As far as I can remember, as I don't have the documentation to hand, there is an FF FF FF FF long word that always appears before the documentation block. And the numbers that you will need are 16 bytes and 4 bytes previous to this. You also know that these are the right numbers and you have a correct lock on them because both MUST have a value in relation to the text within the documentation trigger.

C) In addition, there are other words that mark how long each line is, but you'll know this if you have been reading text out of the objects.

Once again, good luck and tell us how you got on.

Bastiki

Thanks a lot for now...
I'll give it another try and tell u

kine

And I just will add: in some cases, the text itself change how NAV will store the text. E.g. some lines will corrupt the logic I am using in my module for reading object documentation. I know that there are ways how to correct that, but no time to fix it. But you can play with it... ;-)

Bastiki

Does anybody know how Navision stores the Data in the Blob field. It seems to me as if it compresses the data before storing it in the database.
#-o

Currently i use CFront but it often throws an exception when modifying the record. I read the data, put it in a file, read the file into a buffer and write the data in the blobfield using the CFront function SetFieldData. I've already locked the datatable and anything. The input and outputfiles arre identical (no difference). ](*,)

kine

It is not supported way... I never imported the data back into the table...

MTC

I don't quite understand what you mean by data? All that is in the BLOB field is the description of the object, and in certain places NAV will simply leave garbage instead of 00 which can confuse you when trying to compare BLOB fields. Reverse engineering this is no easy job for many reasons, but it can be done with patience and a few months.

I would love to help you more, but like I said, I cannot. I'd have to ask my boss about giving you code to modify the Documentation triggers (it's in C/AL and C++), but I do not think that he would agree to it. Manipulating that BLOB (not like that terrible code protection thing - nothing wrong with the idea, but they have done it in a very dangerous way IMO, and I do not understand why Microsoft have not put their foot down on it) gives a very serious commercial advantage to a partner, because it allows you to do things with NAV that nobody else can do. Some people may call this a hack, but it's not, fobs can be imported from v5 into v3.7 and vice-versa with no problem, the format does not change. However I expect with v5.1+ the Blob is going to disappear.

MTC

Bastiki wrote:

Does anybody know how Navision stores the Data in the Blob field. It seems to me as if it compresses the data before storing it in the database.
#-o

Currently i use CFront but it often throws an exception when modifying the record. I read the data, put it in a file, read the file into a buffer and write the data in the blobfield using the CFront function SetFieldData. I've already locked the datatable and anything. The input and outputfiles arre identical (no difference). ](*,)

I've never done it with C/FRONT, only C/ODBC, SQL, and NAS over MSMQ.