better to use another field and copy the data from the old field to the new field. Changing the size at the DB level will affect your support and may have an impact on migration (you just never know) if you choose to migrate at a later date.
Radovan has developed an update all featrue that will allow you easily move the data from one field to another without having to use DB rules and a trigger.
" better to use another field and copy the data from the old field to the new field. "
While I respect your Mighty-Pharoh-Hat-Power, if Claudia is running OVSD 5.1 the old field to new field copying is just going to eat up one of her precious few custom fields. It works, but the sacrifice is worth noting.
-=R=- the screen shots looks like 4.5 but anyway if under SP 17 ish they have the same probem witl "limited" custom fields. The can update the DB directly and increase the field size there but if they have any problems they could void warranty support. So with tta in mind I prefer to advise people to use an existing larger field. yes you will be one 4k field less but its better to be down the field and in warranty then to void the warranty conditions and fal out of support.
So thats the context of the recommendation. by the way I really struggle with the default problem fields. pre SP 17ish there just was not enough of them.