Object Analysis With Developer's Toolkit

aditya

Hi
Hello
Welcome
I have an a senario

OBJECT ANALYSIS WITH DEVELOPER'S TOOLKIT

Acyually Iwant To Change Description Length 30 To 80 for that Iwant DEVELOPER'S TOOLKIT & Tell me how to Analyis Objects


Any Body Share ur Valuble Ideas
tnks& Regards
adi

kriki

[Topic moved from Navision Tips & Tricks forum to Navision forum]

girish.joshi

This is perhaps the single most common/worst development idea for Navision.

Use the description 2 field instead!!

That being said it is possible, but very problematic.

Here are a few of the issues

1. the description field is pervasive. You end up modifiying your whole database which makes it more difficult to detect bugs related to other development and much more difficult to upgrade.

2. There are a few occassions where the contents of a description field are passed to variables that are not called description. The developers toolkit will help you identify these (very time consuming) but once you do that, then you have to find everywhere the second field is assigned and expand those fields. It gets out of control.

3. Typicall this sort of issue comes up when dealing with a very large number of items. This solution only exacerbates problems associated with very large item, and item ledger entry tables. It almost always makes sense to come up with some kind of item archiving solution.

jlandeen

I cannot agree more strongly. I have seen this time & time again that users want to extend the length of a Name, Description or Code field that is part of the base Navision product. This should be avoided at all cost.

One of the additional problems is that by doing this upgrading and maintaining the database becomes much more difficult.

I always recommend clients to either use another field (like Description 2) or add a new field. So in this case add a "Long Description" field to the Item card that is 80, 100, 200 characters (whatever you need). Then whenever you have to display this (reports, forms, etc.) just simply look it up or add it to another table as a lookup flow field.

jlandeen

Sorry...I assumed this was for an item record...but the same idea could be applied to any base table in Navision.

NavStudent

In Axapta, they've solved this by using inheritance and polymorphism. Let’s hope we get something like this in Dynamics, but a little simpler.

They could in Navision for example, when you declare field or variable of type text, you could instead of specifying the length, and you could lookup and select a new object type called Constants.

The constants would be defined with attributes like data type, (text, code, and any other ones)
Another attribute would be source field (“Item No.”)


Another way you could implement this is that you could add a new property to the field table. Called constant lookup. So where ever you define a field or variable, you could do lookup on length and select the constant fields.



That way when you increase the "Item No.", all the fields that reference the constant would be updated.

jlandeen

It's funny you should mention that...a client the other day was talking about similar functionality of their old Mainframe system that had that "constant" concept.

Certinaly if we had something like that...or some way to inherit between tables it would help solve these kinds of problems.

However after seeing the new 6.0...I don't think we can expect these kinds of rich platform changes anytime soon

idiot

I would see the field lengths problem as an opportunity...
If I'm the boss of the solution center I would maintain a copy navision containing commonly requested enhancements as value-added advantage over others...
In this context I would probably have a database of all descriptions already increased to 60 chars which I can use for all my clients...

girish.joshi

Consultants are supposed to give good advice, not profiteer off of our clients ignorance.

In my experience, there are long-term problems with performing this modification. The difficulty you will have tracking bugs, maintaining the modification, and (most importantly) how it will reduce your options interfacing and upgrading NAV are all nightmares waiting to happen with this approach.

And that doesn't even begin to address the difficulty of doing it in the first place.

jlandeen

Generally I agree that it is a good idea to use those "general mods" in some sort of value added package that you sell/give away to customers to differentiate yourself from other NSC's.

However I do not think that field extensions are a good candidate for something like that, mainly because there is no good generalizable condition. If you were to extend a field to 100 Characters and your customer really only needs 80 you're wasting database & index space (if the field is used in a key). If you have a customer that then needs 120 characters...you have to go through all of the pain all over again (which may not be good use of a developers time). Plus there is also the management overhead of having to integrate those pervasive changes with any new versions or service packs that are released.


On the idea of "profiting off clients ignorance" I don't think that's the way a lot of consultants look at it. We are here to provide good advice and good solutions to our customers. To do that requires talented AND EXPERIENCED resources. The more talent & experience a resource has...the more useful they are to a client...and the more expensive they are too the NSC. So when mods are done repeatedly and someone packages them up and just sells them at a fixed rate it makes it easier & better for everyone. The developers don't have to mindlessly rewrite the same code, the client gets code that has been field tested/tried at multiple sites and generally benefits from it....which is hardly what I would call "profitting off clients ignorance".

girish.joshi

profiteering off the client's ignorance would be packaging a solution you wouldn't normally recommend just because its frequently asked for.

Or with an analogy: no matter how many times a client asks to have his arm chopped off, or how my experience lets me minimize the pain off a chopped off arm, I am still not going to chop off my clients arm! (Even if I have an automatic arm chopper) Why? Because its not ethical to do something you know isn't in their interests (they might need the arm later ).

The reason not to change field lengths is NOT because it is hard to do (which it is) but because, as jlandeen said, it makes it difficult to upgrade and maintain.

idiot

Maybe I haven't implemented a lot of projects, but so far many will have the mentality "if it ain't broken don't fix it", so implemented projects tend to stay status quo for at least one yr.
From the general trend a new version will be released in this one yr & requirements change with time as well. This makes perfect sense to re-implement rather than to upgrade considering the efforts, & those problems caused by long fields gets eliminated, also considering the integration of other systems that support pure SQL...
This is from experience so I'm an advocate of increasing field lengths.

ara3n

edit