Nueva idea: Manejador de registro

Velneo
1

Acabo de poner una nueva idea, si os gusta, os invito a votar:

https://velneo.zendesk.com/entries/97383677-Crear-un-manejador-de-registro

Para los que no tengan acceso, dejo tambien el contenido:

En ocasiones tenemos que copiar valores entre 2 registros que nada tienen que ver entre si, esto nos obliga a usar variables para almacenar los valores del registro, para posteriormente, pasarlos a la nueva ficha en memoria que vamos a crear. Ejemplo:

Recorrer lista lectura/escritura
— Set Var_1 , Campo_1
— Set Var_2 , Campo_2
— Set Var_3 , Campo_3
— Crear nueva ficha en memoria( TABLA , nueva_ficha)
— — Modificar campo ( CAMPO_A , Var_1 )
— — Modificar campo ( CAMPO_B , Var_2 )
— — Modificar campo ( CAMPO_C , Var_3 )
— Alta de ficha (nueva_ficha)

Esto es sencillo cuando manejamos 3 campos, pero imaginaos el proceso cuando la tabla tenga 30 o 40 campos, y mas si son varias tablas.

Solución, que puede haber alguna mejor, pero aquí dejo caer una que se me ocurre:

Recorrer lista lectura / escritura
— Crear manejador de registro ( registro_x )
— Crear nueva ficha en memoria( TABLA , nueva_ficha)
— — Modificar campo ( CAMPO_A , registro_x.Campo_1 )
— — Modificar campo ( CAMPO_B , registro_x.Campo_2 )
— — Modificar campo ( CAMPO_C , registro_x.Campo_3 )
— Alta de ficha (nueva_ficha)

Con este método, nos ahorraríamos crear una variable para cada campo, el código del proceso se vería reducido a la mitad, y por tanto, mucho más limpio y eficiente.

saludos.

2

Saludos:
A modo de intercambio de ideas. Para esta circunstancia yo aplico el siguiente modo:
— Rem ContenidoSeccion0, ContenidoSeccion1, ContenidoSeccion2, ContenidoSeccion3, ContenidoSeccionN
— Set Var , Contenidoseccion0 + “|”
— Set Var , Var + Contenidoseccion1 + “|”
— Set Var , Var + Contenidoseccion2 + “|”
— Set Var , Var + Contenidoseccion3 + “|”
— Set Var , Var + Contenidoseccion4 + “|”
— Crear nueva ficha en memoria( TABLA , nueva_ficha)
— — Modificar campo ( CAMPO_A , stringsection(Var,”|”,0,0,0) )
— — Modificar campo ( CAMPO_B , stringsection(Var,”|”,1,0,0) )
— — Modificar campo ( CAMPO_C , stringsection(Var,”|”,2,0,0) )
— — Modificar campo ( CAMPO_D , stringsection(Var,”|”,3,0,0) )
— — Modificar campo ( CAMPO_E , stringsection(Var,”|”,4,0,0) )
— Alta de ficha (nueva_ficha)

Por supuesto, es un punto de vista adicional.

En circunstancias he tenido que aplicar muchos “Sets” Cero:
Set Varnum1, 0
Set Varnum2, 0
Set Varnum3, 0
Set Varnum4, 0
Set Varnum5, 0

Particularmente me gusta que exista en una version siguiente:

Setfijarunvalor Varnum1, Varnum2, Varnum3, Varnum4, Varnum5 To 0

O sea fijar el valor cero “0” en una línea a varios nombres de variable.

Gracias

3

A mi me gusta la idea,ahorra cientos de SET y el código queda mucho más legible.

4

+1

5

Buenas, se que no es lo mismo pero…VRegisterExtended

Tendrías que crear un pequeño proceso en javascript pero pasando el registro A a JSON y usando el método create podrías asignar directamente los valores al registro B

6

@mrv1

Si, es una solución, pero no es tan limpio, y es mucho mas lento, ademas, de la forma que indicas, todos los valores son convertidos a texto, para luego tener que convertirlos nuevamente a su tipo original. Lo que hace que sea un proceso mucho mas lento y menos eficiente.

También habrá quien diga que para esto están los Tubos, pero un tubo es útil cuando hay una tabla de origen y una de destino, y con este método, podríamos tener varios registros de origen: registro_x , registro_y , registro_z y usar todos esos manejadores en un mismo registro de destino.

saludos.

7

Hola José Luis, idea votada.

No sé que diría el diseñador de la plataforma Velneo ante tan descabellada idea.
Es tan simple y evidente lo que propones que supondría dar la vuelta a años de trabajo.

¿Crear un manejador de Registro? ¿y por qué no un manejador de Lista, de Rejilla o de cualquier Vista de Datos?
Así evitaríamos el uso contínuo de Cestas intermedias y de comandos Procesar lista.

Al final tendríamos en Velneo nativo muchas de las funcionalidades que nos aporta el API con los manejadores VRegister y VRegisterList, pero ¿no es lo que muchos deseamos?

Saludos
Paco Satué

8

A los que experienciaron con Foxpro, para recordar el uso de nombres de variables de las tablas:

Nombre en Tabla:CODEMPRESA
Variable de memoria usado en programas prg: M.CODEMPRESA ó M->CODEMPRESA

Con esto anterior se acompañaba el uso de las instrucciones SCATTER (para leer contenido de tabla hacia variables de memoria M.CODEMPRESA) y GATHER (para volcar el contenido de variables de memoria a sus correspondiente en la Tabla Dbf).

Cargar Lista TablaCorrespondiente

  • Recorrer lista lectura/escritura
    • SCATTER (volcado a variables de memoria)
    • Rem siguen instrucciones segun requerimientos de procesamiento particular usando variables memoria M.
    • GATHER (volcado en tabla fisica )

Es solo un ejemplo.

De foxpro viene la instruccion:
Store 0 to Varnum1, Varnum2, Varnum3, Varnum4, VarnumN

Tambien se podía definir:
Store 0 to M.varnum1, M.varnum2, M.varnum3, M.varnum4

Queda al equipo de desarrollo de velneo compatibilizarlas y/o integrarlas según su arquitectura, eso lo saben ellos.

Gracias

9

@seh,un manejador de lista, excelente, también sería bueno,… Podrías poner un ejemplo de uso, gracias Paco.

En realidad, velneo ya tiene la mitad del trabajo,… Con el comando Copiar ficha en memoria. Pero ahora mismo ese manejador de ficha solo puede ser usado para procesar esa misma ficha. Solo falta que tengamos acceso al registro en memoria desde cualquier otro registro.

10

Los tubos no son la solución, además, si modificamos la estructura de la tabla y alteramos el orden de los campos, el Tubo deja de funcionar. (Yo no uso los tubos para nada, como si no existieran, un objeto que me puede acarrear problemas, para mi queda descartado sin lugar a dudas).

En un tubo, tienes UN origen y UN destino, con esta idea, podríamos tener VARIOS orígenes y UN destino.

La opción de “Copiar ficha en memoria”, es solo la mitad del trabajo que ya la tienen adelantada, pero ahora mismo solo es posible “Procesar esa misma ficha” para crear un registro de la misma tabla, pero NO es posible usar esa ficha como origen para un registro de OTRA tabla distinta, con esta idea, se solucionaría ese problema.

Lo que estoy planteando no es nada nuevo, no estoy inventando nada. En realidad cualquier lenguaje de O.O.P. (P.O.O. in spanish) funciona así, definimos una Clase u Objeto y accedemos a sus métodos y propiedades con sentencias simples que nos retornan el valor solicitado.

11

Como alternativa puedes usar una variable array, que parece que usan muy poco.

12

@Wikan

Gracias por tu aportación, pero vuelvo a insistir, para aclarar un concepto que quizá no haya quedado claro.

Con la idea que propongo, además de las ventajas que tiene, doy por echo que va “implícito” el tipo de campo (Fecha, Numérico, Alfa, Tiempo) y por supuesto, si tiene decimales, el signo, etc…, de modo que cuando asignamos el valor en el destino, lo único que tenemos que asegurarnos es que si en la tabla de origen el campo es de tipo Fecha, en el destino también sea un campo de tipo Fecha, evitando así cualquier tipo de conversión de datos.

Con los métodos que estáis aportando, pueden parecer una solución, y se agradece, pero no son óptimos, porque no es nativo, es poner un parche a un pinchazo, pero el agujero del pinchazo, sigue estando, aunque lo hayamos tapado.

saludos.

Editado:
Además, en el proceso que indicas, has necesitado ademas 8 lineas para guardar el contenido en el Array, cuando “Copiar ficha en memoria( ficha )”, requiere solo una linea para cada registro, si esto lo multiplicamos por cada registro de origen y pueden ser 4 o 5 tablas, tienes que multiplicar (5 tablas X 8 comandos = 40 y pico lineas de comando) que se podrían reducir a una sola linea por cada tabla de origen, es decir (5 copiar ficha en memoria), y luego a recuperar los valores donde haga falta.

Como decía, una chapuza, no es limpio, no es eficiente, y no es L.I.S.

más saludos.

13

El manejador de registro, es básico en cualquier lenguaje, no debería limitarse a un registro, debería ser un manejador de lista de registros como dice Paco, al estilo de un recordset de toda la vida. Esto en velneo ya existe, es la clase vRegisterList, pero necesitamos una implementación más natural dentro de instrucciones velneo, y como se plantea, poder usarla en el editor de fórmulas.

En mi opinión, los manejadores de registro/lista deberían poder ser instanciados como variables (tanto locales como globales) de tipo RegisterList de una tabla en concreto. Con la ventaja de que estas variables podríamos pasarlas entre objetos seteándolas en lugar de usar cestas y ñapas similares. Luego necesitamos una serie de instrucciones para operar con estas variables (Filter, MoveNext, MovePrevious, Find, Sort …), y que estén disponibles en el editor de fórmulas para usar los campos del registro seleccionado. Se podría incluso dentro de Nueva ficha en memoria, hacer una instrucción TransferFields desde el manejador, que resuelva los campos por nombre de forma automática, dejando obsoletos los tubos en muchos de los casos.

En fin, en este aspecto se puede mejorar mucho mucho la usabilidad y la estructuración del código.

14

@Infortic

Gracias, y si, tienes razón,
Yo he puesto la primera piedra, pero la idea de puede mejorar bastante, y solo pretendo que sea eso, una idea
Y que Velneo nos sorprenda con toda una amplia gama de funcionalidades nuevas que sería bienvenidas.

saludos.

15
  • Life is Soft