Record Size Error

bobnavision

Hi All,

I am getting this error when adding new field to customer table.
====
The active field may not take more than 4000 bytes. You must reduce the no. or length of fields
===

whats the best way to work around this.

Regards,

Savatage

Just curious...What's the field type? code/text/decimal, etc

bobnavision

Its a text field( 30 ).

willy

That message will occure when the total size of all fields in the table is bigger than 4000 bytes.

bobnavision

Yes absolutely! what I am looking for is to create a solution for this because I am sure we are going to need more fields in future on the table.

I need advice on how to tackle this problem. Either create a Customer 2 table or using some existing table????

Regards,

thaug

We had a similiar problem when upgrading to 4.0. With all of the extra fields in the Sales Header table, we had a LOT of custom fields, and ended up having to create a Sales Header 2 table.

The biggest problem has been integrating the two tables on one form, since Navision doesn't like it too much. Although you probably can get away with it on a form like the Customer card, since it does not already have a subform. But, plan and test. And especially test in SQL, since it acts a little differently.

Kowa

It is possible to create a second table, but you will not be to set filters on the fields on the second table in a form which has the first table as the source table. You can link them with a GET on the second table ( the primary key must be the same in both tables of course) in the OnAfterGetRecord-Trigger of the form.

ara3n

You can do filtering but you have to write custom filters. One question. Moving to 64 bit server, does it increase the limit?

Miklos_Hollender

I think having a lot of custom fields might be a sign of some conceptual problem. If we can assume these are not functional fields (like extra data used by custom posting logic) but informational fields like how many employees the customer has, I'd strongly suggest to design it in a 1:N relationship instead of adding to the Customer table everything.

thaug

ara3n wrote:

You can do filtering but you have to write custom filters. One question. Moving to 64 bit server, does it increase the limit?

I think the problem is Navision, and has nothing to do with SQL. It seems that it is the limit of the native database, and if you were to allow more for SQL, the code would not be portable to native.

The true SQL limit, at least in SQL 2005, is 1024 columns.

Savatage

Miklos Hollender wrote:

I think having a lot of custom fields might be a sign of some conceptual problem. If we can assume these are not functional fields (like extra data used by custom posting logic) but informational fields like how many employees the customer has, I'd strongly suggest to design it in a 1:N relationship instead of adding to the Customer table everything.

That's why adding insightful comments/Documentation next to custom fields are important.

For us sometimes we update our business practice and old custom fields are not needed anymore.

It's almost like "We found a better way" to do the same task.

So when I go back & read the fields comments it's clear on why it was there & what it did for us even if years have passed. and can be deleted if not being used anymore.