Upgrading from 200 SP1 to R2: fob import ERROR?

mgm

I am upgrading a customized database to R2.
There are fields added to table 36.
I have to import a fob with the new object first, because table 36 had new fields added. So, I can't do it with a .txt merge directly. When importing the fob, I choose: Merge: Existing<-New. This should add the new field to table 36.
But then I get the following error:

You have specified an unknown variable.
PaymentTransLogMgt.
Define the variable under 'Global C/AL symbols'.

What's this? Is NAV now validating/compiling an object when importing a fob???

David_Singleton

mgm wrote:

I am upgrading a customized database to R2.
There are fields added to table 36.
I have to import a fob with the new object first, because table 36 had new fields added. So, I can't do it with a .txt merge directly. When importing the fob, I choose: Merge: Existing<-New. This should add the new field to table 36.
But then I get the following error:

You have specified an unknown variable.
PaymentTransLogMgt.
Define the variable under 'Global C/AL symbols'.

What's this? Is NAV now validating/compiling an object when importing a fob???

Hasn't it always done this? I mean since the first version of Financials. I don't think this is a new issue.

mgm

As far as I know this is something new.

How to upgrade customized objects?
I always did like this:
- export customized objects to .txt file
- export new version objects to .txt file
- merge objects with text compare tool
If new table has new fields, then import this table from .fob with Merge: Existing<-New.
This adds the new fields to the table.
- import the merged .txt file.

If I don't import the fob, but the .txt directly, then I get an error saying I am not allowed to create a field in the 0..49999 range.
That's why I have to import the fob first.

ara3n

when using merge, you need to first remove all the code that references the fields from the two tables.

mgm

But is this something new?
Before I could just import any fob into any database, without NAV checking references. It only checked if I was only limited to object and fieldnos.

David_Singleton

mgm wrote:

But is this something new?
Before I could just import any fob into any database, without NAV checking references. It only checked if I was only limited to object and fieldnos.

That is definitely not the case. Definitely in older databases it has always been like this. I just thought maybe 2009 allowed merging with code, since I haven't even bothered to try it I don't know.

mgm

Ok David,
You are right. Not any fob in any database. But it was possible to import a fob in a database and when compiling the imported objects, it might happen that the just imported object does not compile (gg. a form with a reference to a field that does not exist).
Now this seems changed.

David_Singleton

mgm wrote:

Ok David,
You are right. Not any fob in any database. But it was possible to import a fob in a database and when compiling the imported objects, it might happen that the just imported object does not compile (gg. a form with a reference to a field that does not exist).
Now this seems changed.

Let me make this clear.

The action you are describing has been valid in EVERY version of Navision from 1.1 through to 4.00SP3. I have not tested it on later versions since I assumed it was the same. So I am saying that maybe what you are describing was possible on 2009, but that R2 reverted back to the old way.

I do seriously doubt it though.

Importing an object (e.g. form) where a field is missing from the source table has ALWAYS been possible. That is a completely different and totally unconnected process and has no point in this discussion since it is unrelated.

mgm

David,

You are right again.
And I did some testing. There seems to be no difference between the SP1 and R2 client when importing fobs. :oops:

Somehow I thought (to remember) that the merge option when importing a fob could be used to import a table with new fields and that NAV merged the old and new table into a table with both the old and new fields.

Maarten

rsaritzky

mgm wrote:

As far as I know this is something new.

How to upgrade customized objects?
I always did like this:
- export customized objects to .txt file
- export new version objects to .txt file
- merge objects with text compare tool
If new table has new fields, then import this table from .fob with Merge: Existing<-New.
This adds the new fields to the table.
- import the merged .txt file.

If I don't import the fob, but the .txt directly, then I get an error saying I am not allowed to create a field in the 0..49999 range.
That's why I have to import the fob first.

I'm thinking on my feet, and I admit it may not be great idea, but if the problem is with a new standard field in the 0..49999 range, what if you:

a. Saved your current table 36, including data (that's why this may not be a great idea - you'd have to dataport all the data out).

b. Replace your current table 36 with a "vanilla" R2 Table 36. (This is where you may have to delete all the records in the table).

c. Now merge your custom table 36 into the R2 Table 36 via your text-merge technique.

d. Dataport your data back in.

This is kind of "parallel" to a version upgrade - you merge your custom code with the existing new code, but do it in an empty database.

Again, may not be the best option, but at least it's an option?

ara3n

You are suppose to merge your objects in an empty database. Once all objects are merged and ready then you load the fob into the database with data.

If you are doing a full upgrade that requires upgrade toolkit, then you load it after Step 1 based on the directions provided in the upgrade toolkit.

No need to do any dataports.

rsaritzky

Rashed's right - from the department of "duh" <grin> - do the mod/merge in a database that HAS no data. Once it's complete and compiled, export it and import it into your test or live database.

mgm

Thanx gentlemen.
It's clear again.

ps. time to finish this year, and make a fresh start...