You can't just widen a column in a table in the database and expect Sage 200 to recognise it as such, so the behaviour you're describing isn't surprising.

I'm not sure where this idea of 'staging tables' has come from, as that isn't a thing in Sage 200. The truth of the matter is that the layer of Sage 200 that sits directly above the database - which maps the tables into objects - uses hard-coded metadata to describe the underlying table structure. So for example a field will have metadata that descibes its database column as being a varchar(20). Even if you widened the database column, you can't modify this metadata (or at least - not very easily, not in every instance, and not without a great deal of care) to let the object know that the column it maps onto has changed. So data will either get truncated as it's persisted to the database - or you'll get some kind of error.

There are solutions to your issue though, as Sage 200 developers are able to extend the existing tables to add new columns and extend the reporting model to enable those columns to appear on documents. Of course this would require some kind of custom import routine, but it's the kind of job I'd put onto the 'reasonably simple' pile.

Not sure we are talking about the same thing.  (Sorry my English and sorry my technical knowledge)

Our consultant told us there is no problem on customizing text fields (i.e. some description) by expanding its length.  Changing data type should be more problematic.

That was told as such, and indeed some fields have been expanded without problem, and editing content inside sage200 works ok.

Sure I am not talking about changing the columns on the table behind sage200, I presume this is done through some sage200 customization, and thus, the tables-to-object-layer is adapted accordingly (Something like that I remember from SAP).

And it seems the problem with those “elongated” fields is in some sort of intermediary tables created between the CSV and the final tables.

Again, not sure how much this makes sense, as I am talking from wording received from the consultant.

About your last sentence, that would make perfectly sense.  But it clearly conflict with what we have been told: Customizing internally = easy, carry on this customization to allow longer texts from CSVs = impossible.

(may you notice I am not so sure our consultant really knows how to work professionally in sage?)

When I talk about Sage 200 I'm specifically referring to the product sold in the UK.  I'm aware of products being sold under the Sage 200 name in other parts of the world (like Sage 200 Evolution in the Middle East).  Are we talking about the UK version of Sage 200 here?

I presumed to be the sage product, sorry.

But we got it from Spain (company owner is from argentina and contract it with spanish firm, software is also in spanish)

Ok - that's why I was confused about the intermediary tables. The Spanish Sage 200 is a completely different product to what is sold as Sage 200 in the UK. They just have the same name.

You should post your question here :

https://www.sagecity.com/es/sage-200cloud-espana/

Buenaventura!

opsss,
thats weird, but nice to know,

I will ask on the spanish forum

thanks a lot