Application: gvSIG desktop

Añado más información: Si edito la tabla con los campos unidos, y con la calculadora de campos relleno los que se habían quedado con "S" como "SÍ", sí que se van viendo los cambios al darle a "Aplicar" en la calculadora de campos tras cada rellenado, pero al darle a Aceptar para finalizar la calculadora se vuelven todos los textos anteriores como "S".

Lo hemos probado en otro equipo con Ubuntu, y ha saltado error. Adjunto el log con la información. Además ha dejado gvSIG bloqueado.

En Windows lo hizo bien una vez, pero al abrir la tabla en Linux después salían vacíos los campos unidos. Al final pude hacerlo por Unión de tablas en Windows (en Linux también fallaba esto)

El error no tenia nada que ver con los acentos.
El problema es que era un campo booleano y se habia indicado que ese campo tenia longitud 2, y luego se trataba de introducir en ese campo los valores "Sí" o "No". La longitud de campo en el dbf, no es el numero de caracteres del campo, si no el numero de bytes de este. Para el valor "No", son 2 bytes, pero para el valor "Sí" son 4 bytes, ya que la i acentuada son 4 bytes. El proveedor de dbf, cortaba el valor del campo a 2 bytes y quedaba corrupto el valor, presentando un valor extraño en lugar de una i acentuada.
Se ha modificado el el proveedor para que informe en el log cuando se intenta escribir un valor mas largo del soportado en un campo, indicando sobre que campo ha pasado.

Ademas de esto, el proceso de importar cambios, mostraba por la consola un error de modificacion concurrente. Esto se debia a la forma en como se recorren las features ya editadas. Se ha modificado la forma en como se itera para evitar este problema.