Navision draconian rule on field creation

NavStudent · 2007-11-16

Navision has the rule that custom fields should be created in 50K to 99K ranges, which I understand.
What I don’t understand is why they don’t allow importing of txt files especially when I’m merging two add-ons to be merged.
It’s a pain in the butt to do what they require us to do. This makes upgrades so tedious. You spend hours creating temporary db load the fob, select merge, and clean the code. Import the txt in there compile and load in the final db.
Why don’t allow us to at least add the fields through import of txt.

They can still prevent creation of objects, I don’t care but any other developer in other systems would laugh if you tell them that this is what you have to do for an upgrade.

p.willemse6 · 2007-11-16

what does this have to do with NAV 6.0?

NavStudent · 2007-11-16

They should change it for next release.

The upgrades will be hard enough anyways.

It'll make developer lives a lot easier.

p.willemse6 · 2007-11-16

OK

jlandeen · 2007-11-16

I agree that this would certainly make upgrading integrated add ons much easier & faster if we could load modified text objects. It certainly has been a big problem in the past.

My only concern here is that it's not something that I do on a regular basis for me to really complain to MS. There are many other features that I would rather have then being able to import text objects. Like a more .Net like development environment, better debugger.

NavStudent · 2007-11-16

I am not asking to build a new IDE, it's simply a licensing enforcement.

And if there is some code change, it would be minor.

And they can put this on their next PowerPoint presentation that we've made it easier to upgrade!

The Salespeople and bosses will be extremely pleased, since now they have one more bullet point they can talk about.

This new feature will be so irresistible that clients won’t think twice about upgrading.

Waldo · 2007-11-16

It's indeed a pain in the butt.

I created a workaround to merge two add-ons. It comes down to:
- create tables without code and fields with those numbers
- create fob
- import fob: Merge Existing <- New
- import merged textfile.

Once, I put a download on Mibuso:
http://www.mibuso.com/dlinfo.asp?FileID=817
This tablegenerator creates the tables for you without code.
Import the generated text file in (a copy of) the existing database where you uploaded the Add-On in, compile the tables, export as fob and import it in the database where you would upload your merged textfile in (import Merge Existing <- New). Now, your fields that you couldn't create, are created.
Remember to work with databases without data (so without companies).

When you have your merged text files, it just takes an extra 10 minutes with this workaround for all your tables.. (no matter how many).

NavStudent · 2007-11-16

When you are upgrading a db that has 500 objects modified, has 4 addons, it's not easy.

You are waisting many hours for the merging. There are many other things I have to look, such as make sure the addons work correctly, the merging is done properoly than waste my time with this.

Navision is about KISS and RIM.

WTF are they doing this for?

Also when you are "Merge Existing <- New", Why do they have compile and error out if some code is run for a field that is about to be created.
Let it merge and let the user compile it.

kriki · 2007-11-18

[Topic moved from Upcoming version NAV 6.0 (formerly NAV 5.1) forum to Navision forum]

kine · 2007-11-19

The limits are there to prevent creation of fields with IDs outside permitted range. If this will be allowed, everybody can modify the text file and create own fields outside the permitted range. In this case, we do not need the limits because there will be an easy way how to go around. I am not expecting change in this area... :-s

Waldo · 2007-11-19

It's indeed one or the other, and I expect MS to go for the licensing one

.

I'd like to see the AX way of versioning integrated in the C/SIDE environment. But I don't expect this ever to happen

. Merging multiple add-ons into one application could be done without workarounds ... .

Anyway, in my workaround, for merging 4 addons, I just have to repeat the process 4 times. So, it's an extra 40 minutes, instead of 10 minutes. I can live with that O:) .

NavStudent · 2007-11-21

kine wrote:

The limits are there to prevent creation of fields with IDs outside permitted range. If this will be allowed, everybody can modify the text file and create own fields outside the permitted range. In this case, we do not need the limits because there will be an easy way how to go around. I am not expecting change in this area... :-s

The designer in Navision should still error if you try to insert in license that is outside of your license. Loading in text is perfectly fine.

As long as you can't create new tables, there is no issue.
And anybody who goes out of their way and creates a field in million range is shooting themselves in the foot.

Just because somebody can write in a report.
SalesHeader.deleteall;

doesn't mean we should prevent through license to use that function.
It just looks too stupid.

Just because you have no expectation in this matter, doesn't mean that they wouldn't and shouldn't do it.

NavStudent · 2007-11-21

Waldo wrote:

It's indeed one or the other, and I expect MS to go for the licensing one .

I'd like to see the AX way of versioning integrated in the C/SIDE environment. But I don't expect this ever to happen . Merging multiple add-ons into one application could be done without workarounds ... .

Anyway, in my workaround, for merging 4 addons, I just have to repeat the process 4 times. So, it's an extra 40 minutes, instead of 10 minutes. I can live with that O:) .

I don't see MS loosing anything on allowing import of txt files.

Alex_Chow · 2007-11-21

Waldo wrote:

I'd like to see the AX way of versioning integrated in the C/SIDE environment. But I don't expect this ever to happen . Merging multiple add-ons into one application could be done without workarounds ... .

I hope this never happens! It'll make C/SIDE more complicated than it should. It may help you when you merge multiple add-ons together, but for everyone else, it'll be a nightmare they can't wake up from.

Alex_Chow · 2007-11-21

NavStudent wrote:

I don't see MS loosing anything on allowing import of txt files.

That's because you're not Microsoft. You don't know what they're thinking but only think they should do a certain thing to satisfy your needs.

Not to say that you're not right, by the way.

Waldo · 2007-11-21

Alex Chow wrote:

Waldo wrote:

I'd like to see the AX way of versioning integrated in the C/SIDE environment. But I don't expect this ever to happen . Merging multiple add-ons into one application could be done without workarounds ... .

I hope this never happens! It'll make C/SIDE more complicated than it should. It may help you when you merge multiple add-ons together, but for everyone else, it'll be a nightmare they can't wake up from.

If one can understand how menusuites work (storing only the changes compared with previous saved version), then you would understand it for every object.

I know that there is only one menusuite in stead of multiple tables, reports, ... . That means that for this, MS would have to create a second level for every object that stores the versions.

Anyway, don't worry ... this will never happen

Waldo · 2007-11-21

NavStudent wrote:

Waldo wrote:

It's indeed one or the other, and I expect MS to go for the licensing one .

I'd like to see the AX way of versioning integrated in the C/SIDE environment. But I don't expect this ever to happen . Merging multiple add-ons into one application could be done without workarounds ... .

Anyway, in my workaround, for merging 4 addons, I just have to repeat the process 4 times. So, it's an extra 40 minutes, instead of 10 minutes. I can live with that O:) .

I don't see MS loosing anything on allowing import of txt files.

Importing a fob is importing a compiled object. This way, MS is sure it was compiled by a license that was permitted to create a field in that range. Therefore, merging is ok (I guess).

Importing a text file is like writing code. You still have to compile the object. So, you're adding the field, and you're not permitted to do that with the license, so it errors out.

So for me, it's a licensing issue.

Furthermore, this way has some advantages as well:
- Putting an option between already existing options
- version upgrade of automation
--> I won't go into it too deep, but these things can cause big trouble, and is easily to work around with text files... .

NavStudent · 2007-11-22

Waldo wrote:

NavStudent wrote:

Waldo wrote:

It's indeed one or the other, and I expect MS to go for the licensing one .

I'd like to see the AX way of versioning integrated in the C/SIDE environment. But I don't expect this ever to happen . Merging multiple add-ons into one application could be done without workarounds ... .

Anyway, in my workaround, for merging 4 addons, I just have to repeat the process 4 times. So, it's an extra 40 minutes, instead of 10 minutes. I can live with that O:) .

I don't see MS loosing anything on allowing import of txt files.

Importing a fob is importing a compiled object. This way, MS is sure it was compiled by a license that was permitted to create a field in that range. Therefore, merging is ok (I guess).

Importing a text file is like writing code. You still have to compile the object. So, you're adding the field, and you're not permitted to do that with the license, so it errors out.

So for me, it's a licensing issue.

Furthermore, this way has some advantages as well:
- Putting an option between already existing options
- version upgrade of automation
--> I won't go into it too deep, but these things can cause big trouble, and is easily to work around with text files... .

All this makes sense for Tables, And your advantages aren't realy advantages because it would apply to txt as well.

The only people who import txt are when the upgrade, people who want to create for some unknown reason a field in million range, well they are shooting themselves in foot. The only way you should be able to do it is through txt file.

Either they need to change the license, or don't compile tables when you choose to merge two tables in import worksheet.

Navision draconian rule on field creation

Comments

Categories