Some questions about importing.

CRinv

As I have stated in another thread, my company makes custom additions to Navision. One of our products require that the user has seven custom fields in the Customer table in the database. We would like to provide our customers with a fob that they can import that will add these fields to the Customer table. What I've found out so far is that we can export a fob of a Customer table where we have added the wanted fields and distribute this to our customers who can now import this, and via Merge: Existing <- New they can add the required fields to their table.

What I need to know, though, is that this is safe and won't corrupt their Customer table in any way, i.e. it won't write over any changes they have done to pre-existing fields, and it won't remove any additions they have made themselves.

I hope someone can shed some light on this question for me. Thanks!

DenSter

No that simply won't work. Any custom fields and other functionality must be merged outside of the Navision import worksheet. The merge function on the import worksheet is not reliable enough.

CRinv

Thanks for the quick reply. Would you care to elaborate a bit more, as you might understand I'm a bit of a newbie at this.

In my tests so far, this way seems to have worked fine. I'm, of course, not saying you are wrong, but what kind of things do you mean can go wrong, and such? The premise for this is of course that the customer has the ID:s we use in the customer table available, and no fields with the same names.

DenSter

Theoretically it should work, and if it is just fields there should be no problem, but it is too risky. You just can't rely on the import worksheet, and you can also not rely on the user opening the import worksheet to select 'merge <- new'. When Navision finds no conflict in the object when you improt it then it is very easy to bypass the import worksheet.

I don't mean to make this more difficult than it is, but in my experience these little things can have big consequences. It's no trouble to put 7 fields in for a customer, so you could even offer it to your costumers as a service. 'send me your customer table and we'll merge the fields in for free' kind of deal, sounds good eh .

kine

The Merge function in import sheet works in this way (it is described in help):

Merge: Existing<-New
It will add new fields from the fob but all variables and code will be transfered from old object (you are not able to add new code)

Or

Merge: New<-Existing
It will add new fields from the fob and all variables and code will be transfered from new object (you will overwrite any customer changes made in code)

But you are not able to add the field with some code and have still same code from old object (combining two C/AL code in one object). This is the main problem (and that customer can switch the type of the merge and all customizations are lost)