Compactar archivo contenedor CND

Hola.

Usando la Open App vVersions me he dado cuenta de lo rápido que suben los backups y se debe al crecimiento descontrolado del contenedor donde se van guardando las sucesivas versiones de los proyectos (Tabla versiones).

Una vez borradas las versiones antiguas, las instrucciones de Regenerar Datos e Índices no afectan al tamaño del contenedor. El comando Limpiar Campo Objeto únicamente deja en blanco la parte ocupada del contenedor.

En definitiva, no hay manera de reducir el tamaño del contenedor una vez ha alcanzado unos cientos de Megas. Para complicar más las cosas, Velneo no fragmenta el contenido de un campo objeto, sino que busca un espacio en blanco que sea lo suficientemente grande, por lo que no optimiza el tamaño.

La Solución de Soporte pasa por duplicar la Tabla en el Proyecto y Traspasar los datos para que se cree un nuevo Contenedor compactado. Pero esto implicará renombrar la nueva tabla a la original.

Mi pregunta es ¿Cómo solucionáis esta Tarea de compactación? ¿Qué Procedimiento seguís con Aplicaciones en Producción?

Gracias y un saludo
Paco Satué

Por supuesto, yo lo solucionare a manita. Parada de servidor, compactacion manual de CNDs, y puesta en marcha otra vez. Eso cada 3, 4 o cinco años. Cutre pero… es lo que haré…

Esperemos que el precio de los discos duros siga bajando je, je… Y que vServer no se atragante con CNDs gigantes…

Interesante el dato de que los objetos se almacenan sin trocear… yo pensaba que los paginaria y almacenaría en trocitos… pues no…

Por otra parte, esto parece una tarea típica que debería hacer Velneo… No puede ser muy difícil hacer una rutina nativa que compacte el CND… aunque sea “en frio”…

+1

Hola.

Conclusiones al tema del fichero Contenedor de campos Objeto CND:

  • No hay utilidad nativa (ni se espera que haya) para la compactación de los ficheros.
  • Procedimiento para la compactación a pedal.
    1-Duplicar tabla en Diseño 2-Prohibir la entrada a los Usuarios 3-Traspasar los datos de una tabla a la otra (me miraré los Tubos) 4-Parar el servidor 5-Renombrar la nueva Tabla sobreescribiendo la original 6-Quitar del proyecto la tabla duplicada 7-Poner en marcha de nuevo
- El contenido de los campos Objeto no se fragmenta y por lo tanto siempre habrá huecos no utilizados. - El comando "Crear copia de ficha en memoria" NO DUPLICA la parte del contenedor CND, solo duplica los campos de la tabla dat. (ver la info siguiente). - Los campos Objeto que se modifican, aunque solo sea añadir una palabra de 3 letras, o incluso quitar un punto, obligan a la base de datos a crear un nuevo puntero y duplicar de nuevo el contenido del campo Objeto en el fichero CND.

Así que teniendo esto en cuenta, vuestros ficheros CND pueden crecer rápidamente en aquellas aplicaciones donde vaya a existir mucha edición de campos Objeto.

Si tenéis alguna técnica de optimizar los ficheros CND, pues la compartís.

Saludos
Paco Satué

Buenas tardes:

La “solución” a ese “problema” que yo vengo aplicando (desde hace casi 15 años, primero con V6 y ahora con V7) con razonables resultados es que en los casos de objeto Texto o Texto enriquecido NO uso contenedores.

Lo que hago es partir el contenido del texto a grabar (editado en una variable) en trozos de, por ejemplo, 400 caracteres y grabarlos en un par de Tablas externas de tipo Cab-Lineas, que hacen la función de “Contenedor” compartido para diferentes Tablas (las que me convenga).

La Tabla Cabecera no tienen relación directa (no es Plural) con las Tablas cuyos Textos grabo en la Tabla de Lineas (que si es Plural de la Tabla Cabecera), relacionándose a través de los conceptos “Módulo+Tabla+Registro+Campo”.

De esta forma puedo añadir “Campos Objeto Texto o Texto Enriquecido” (virtuales) incluso sin modificar la estructura de las Tablas, aunque habitualmente la definición de esos “Campos” la hago en fórmulas alfabéticas (ver imagen) cuya fórmula representa el identificador que va a tener el enlace en la Tabla Cabecera de los Textos (en donde, por supuesto, el campo es un campo físico).

La gestión de contenidos la realizo con funciones de tipo Get-Set.

Como dije al principio, uso este procedimiento desde hace muchos años. Tiene alguna desventaja pero me compensa…

Saludos. Ramiro

image

Hola Ramiro.

Me apunto esta técnica, muy ingeniosa.
Se complica un poco el tema de modificaciones de los textos al tener que gestionar manualmente la tabla plural de textos.
Las búsquedas por Trozos se realiza directamente en la tabla plural de textos, acotando los registros buscados por el campo de la tabla Cabecera.

Gracias y saludos
Paco Satué

Buenas
Después de 7 meses, ¿hay alguna solución nueva a este tema?
en mi caso creo que es debido a un campo objeto imagen que me va subiendo de megas

Si, como dice Ramiro, pongo este campo en otra tabla de extensión, ¿Podría funcionar bien?

gracias

Igual y digo una burrada del tamaño del mundo, pero no se, puede que sea funcional.

¿Y si guardáramos ese tipo de campos en otra base de datos como MySQL?, vamos, la base de datos “externa” en el mismo equipo y hacer la conexión tanto para grabar como para leer los datos, si, llevará algo de trabajo, pero entiendo que quizás otras bases de datos optimizan de mejor manera ese tipo de contenidos.

Pue’que funcione, cuestión de probar.

Saludos.

Martín.

Buenos dias:

En el caso de los textos (plano o Rtf) de longitud variable yo no uso Contenedores (ver mi respuesta de Abril en este mismo hilo). La solución de grabar las Notas (previo troceado) en tantos registros como sean necesarios de una tabla auxiliar normal aporta la ventaja de que el mantenimiento (y por tanto el control de crecimiento) de esa tabla es estandard.

Supongo que se podría hacer algo similar con las imágenes. Si se convierten a Base64 ya son un texto y como tal texto ya se podrían grabar como tales usando la técnica antes mencionada.

El tema me interesa pero esa parte no la tengo implementada porque no conozco la forma de convertir una imagen de cualquier tamaño a Base64. Si alguien me proporciona la rutina para hacerlo con V7, lo pruebo y después lo publico.

Saludos. Ramiro

Buenas,

  • 1 a vuestras aportaciones.

Me parece increible que Veleno no tenga solucionado este asunto y que la gente de la comunidad tenga que buscar parches/soluciones que tendría que dar la plataforma (como hacen todas las demás).

Saludos,
Santiago.

Hola Ramiro.

En el siguiente hilo tienes un ejemplo de cómo manipular imágenes en memoria mediante la clase del API ByteArray.

En la ayuda del ejercicio busca por ByteArray y te mostrará el código necesario para obtener un String de una imagen en disco.

Saludos
Paco Satué

Gracias, Paco…

En su momento había visto tu ejemplo (magnífico) pero no había visto el botón de ayuda. ¡Las prisas…!

Lo probaré…

Saludos. Ramiro

Buenos dias:

He probado las funciones Js documentadas por Paco en orden a la conversión de imágenes a Texto-Base-64. Si esa conversión fuera rápida los textos podrían grabarse por trozos en campos alfabéticos de una tabla auxiliar, evitando el uso de contenedor…

Para las pruebas he creado un formulario con una caja de texto y un objeto dibujo (condiciones de visibilidad alternas) según se ve en la Imagen adjunta. Selecciono una imagen, la cargo usando Js y su contenido (en Base 64) se visualiza como texto o como imagen.

He probado a cargar 4 imágenes JPG que estaban por el disco. Las dos más grandes son Fotos digitales (una antigua y otra reciente con resolución de 13 Mpx). Los tiempos indicados se refieren a lo que tarda el equipo en pasar la imagen a Base-64

Imagen 1 - 0034 Kb - Longitud del texto en Base 64 00020 Kb - menos de 1 segundo
Imagen 2 - 0021 Kb - Longitud del texto en Base 64 00264 Kb - unos 5 segundos
Imagen 3 - 0295 Kb - Longitud del texto en Base 64 02068 Kb - varios minutos
Imagen 5 - 5870 Kb - Longitud del texto en Base 64 22317 Kb - unos 15 minutos

Los resultados sorprenden porque imágenes de tamaños relativamente similares (34 y 21 Kb, las dos primeras) generan representaciones en Base 64 de longitudes muy dispares (de 20 a 264 Kb). Por otra parte los tiempos de conversión a Base 64 de imágenes muy grandes son simplemente inaceptables y además parecen crecer en progresión geométrica.

La presentación de la imagen en el control objeto dibujo (a partir del texto en Base 64) fue en todos los casos correcta, por lo que los problemas (con imágenes grandes) son los tiempos de conversión y supongo que también los tiempos de grabación. No he llegado a probarlo pero si quisiéramos grabar la imagen 5 (cuya variable en Base 64 tiene un longitud de 22.317 Kb) en campos alfabéticos de longitud 1000 necesitaríamos 22317 registros…

La verdad es que no lo veo como alternativa válida salvo para imágenes de tamaño reducido.

Saludos. Ramiro

image

Tengo un fichero de 6.5 gb con fotos, he reducido el tamaño de las imagines considerablemente, pero necesito compactar el fichero contenedor, hay alguna solución más sencilla que la que propone “seh” al principio de este post, tiene velneo alguna otra solución??

Hola GSI.

Los que mejor te pueden contestar son los de Soporte. Ellos son los únicos que saben cómo funciona realmente la gestión de los ficheros CND.
La solución que yo expuse en su día era la que oficialmente obtuve de Soporte. No creo que haya variado.

De todas formas tampoco lo veo tan complicado. Tienes varias opciones:

  • No compactar nunca, hoy en día ya no hay problemas de disco, incluso para los backups.
  • Procurar guardar las imágenes definitivas en la tabla. Escalar las imágenes antes de guardarlas. Si las imágenes van a ser editadas constantemente, desechar el uso de CND y gestionar directamente las imágenes en disco.
  • Si finalmente, no hay más remedio que compactar periódicamente, quizás lo más práctico es crear una Tabla de Extensión con un solo campo Objeto imagen. De esta forma el traspaso de datos a un nuevo CND es menos traumático.

Saludos
Paco Satué

Pensé que quitando uno de los campos objeto que pude prescindir de él haría un recreado de la tabla cnd, pero no fue así, el archivo quedó exactamente igual ahora comprendo lo de que con nada en este mundo se puede compactar el archivo.
Ahora la solución de Paco (que le propusieron en soprte técnico):
1-Duplicar tabla en Diseño 2-Prohibir la entrada a los Usuarios 3-Traspasar los datos de una tabla a la otra (me miraré los Tubos) 4-Parar el servidor 5-Renombrar la nueva Tabla sobreescribiendo la original 6-Quitar del proyecto la tabla duplicada 7-Poner en marcha de nuevo

Me dió terror!!! ¿Qué pasa con los enlaces a otras tablas? ¿Qué pasa con las actualizaciónes? ¿Los procesos que se debieron de correr en su momento en los trigger no se duplicarán al momento de pasar los datos de una tabla a otra?
Se me hace un procedimiento altamente riesgoso. ¿Con la versión más reciente de velneo no hay alguna opción alterna que no sea tan agresiva como esta?

Pregunta, si creo una tabla como “Maestro de extensión” solo con el campo objeto en cuestión. Inicializo el campo con el mismo valor que el de la tabla original. Elimino el campo. ¿Se borrará el archivo CND y su indice?
Incluso, si no se borran, al no tener ya necesidad de esa información en ese archivo por que se ha movido a otro (imagino que la tabla “Maestro de extensión” creará sus propios archivos) se pueden borrar y el servidor en caso de requerirlos los creará vaciós o no los creará si no los necesita de plano.
Finalmente si no se quiere manejar la tabla de extensión se puede volver a crear el campo y regresarle los valores y eliminar la tabla de extensión.
Todo esto es un supuesto que justo se me acaba de ocurrir, en su momento haré una prueba a ver que resultados obtengo y se me hace menos agresiva que la propuesta anterior en el sentido de que no creas nuevos registros que pudieran tener afectaciones en otros valores o relaciones y se pueda hacer un caos.
En cuanto tenga una noticia sobre esto les comento, pero igual espero sus comentarios por si algo de mis suposiciones es incorrecta.