two addons conflict

ara3n · 2006-07-31

Hello Running into this problem. I have two addons to merge and they both insert fields into Sales Header. The problem is that bot exceed 4 K limit for size and I have to disable fields. Both addons are Big. One is E-Ship, the other some European addon.

ara3n · 2006-07-31

I guess the only option is to cherry pick fields they woulnd't use. :-k

zeninoleg · 2006-07-31

And hope there ARE fields that they do not use..... [-o<

ara3n · 2006-07-31

well since we are consultants, we can consult them not to use the fields. The problem is that with any new project, they will ask to add new fields to sales header, and guess what, we wouldn't be able to cause we have run out of fields. So we have to create a second table for this, and add a another table for posted documents. GRRRR.

Is this a synthetic limitation on SQL because Native has this limitation? Will this be removed in v 5?

kriki · 2006-08-01

BlackTiger wrote:

No. SQLServer has own limit - 8k per record.

I thought it was 6k per record. :-k

kriki · 2006-08-01

BlackTiger wrote:

In SQL2005 - 8K

AAAAAHHHHH!

DenSter · 2006-08-01

You can add a table with a 1-to-1 relationship to the Sales Header, and maintain records in the table triggers. You'll have some coding to do though...

Miklos_Hollender · 2006-08-02

Actually I'd suggest to disable standard fields you are surely not using. Adress 2 - that alone saves 30 characters. Bill-to Address 2 - another 30. Etc.

ara3n · 2006-08-02

Thanks Miklos.

Denster. I don't want to maintain the two Addon and rewrite most of the code.

DenSter · 2006-08-02

You don't have to rewrite anything, just a bit of code to maintain field values.

Miklos_Hollender · 2006-08-02

Another idea. Move the all the sell-to and buy-to name, name 2, address, post code etc. to another table and link it by primary key. It saves a LOT of space and at least these fields don't have much business logic associated with them (just the adress formatting in documents). Especially that I think you in the USA have more address fields than in the worldwide standard.

DenSter · 2006-08-02

I don't think you can do that. If you sent an invoice to customer A at X address, and they move to Y address, you want to be able to print out a historical invoice with the address that it was actually sent to.

Miklos_Hollender · 2006-08-02

Exactly so.

However:

1) Maybe the Shipment Header / Invoice Header does not contain so many fields so they can be kept, and only three things changed a) filling these fields b) moving them to invoice and shipment 3) printing of Order Confirmation.

2) Even if it's not the case, they also can live in the new table. I mean the primary key of the new table could be like, Table No., Document Type, Document No. And copy it upon posting.

They reason I strongly suggest it that these code are easy to find, easy to change, and not likely to change much in later versions. I think it's easier to change it than changing something that's connected with some sophisticated business logic that lives who knows where. At least we know that the ledgers etc. don't need these fields, so the important parts of the busness logic is kept safe. Besides, these fields really eat up lots of space. There are not many 30-char fields in Sales Header except for them.

ara3n · 2006-08-11

I've solved it by disabling some of the fields in one of the addon. It had 4 text field of length 250. The data came from some setup. Pretty useless feature.

kriki · 2006-08-11

ara3n wrote:

I've solved it by disabling some of the fields in one of the addon. It had 4 text field of length 250. The data came from some setup. Pretty useless feature.

Luckily it was a useless feature, otherwise you wouldn't have been able to disable the fields.

ara3n · 2006-08-11

Lol even if it was usefull, they would just not get that feature. The client is just starting using navision. 4 less fields out of 30000 won't make a difference, and the client wont' even notice it.

girish.joshi · 2006-08-15

Mikos, it probably is a good idea to disable fields on the sales header that they don't use -- but I'd limit it to fields associated with unused, and probably never used granules. If not, you might have rewrite a lot of standard navision! If we moved Address 2, for instance, just think of how many standard reports won't compile!

ara3n · 2006-08-15

Actually most of the report use formataddress codeunit to format the address. So it won't be that many.

Howdy, Stranger!

Quick Links

Categories

two addons conflict

Answers