mar
1
Si, asi es, y sintiendolo mucho, tengo que pedir disculpas, …
… porque aunque me gusta cumplir las promesas que hago, os recuerdo que ayer finalizó el plazo de presentación de aplicaciones al II concurso de Open Apps.
Y lamentandolo mucho, os habia prometido en alguna ocasión, que presentaria una aplicación llamada “Foro de ideas”, y no ha podido ser, la aplicación está iniciada y cuando tenga tiempo para continuarla la enviaré, aunque sea fuera de concurso, pero ando un poco liado, y no he tenido más tiempo.
Asi que, debo decir que no he podido presentar una sola aplicación al concurso.
Espero que podais comprenderlo y ya veré como solucionar este contratiempo.
Otra vez será!!
feb
14
NOKIA WARS
Episode VII: El imperio contra Meego
Hace mucho, mucho tiempo, en una galaxia muy, muy lejana …
Tras la avalancha de comentarios que han suscitado las últimas noticias sobre la cooperación entre Windows y Nokia, sobre como Nokia va a instalar el maravilloso Windows Phone 7 en sus terminales móviles, sobre como Meego va a desaparecer, sobre como QT será abandonado, y como aparece un nuevo protagonista en esta historia, ….
¡¡¡Señores!!! (y no es discriminación machista, es simplemente, que no he visto ningun comentario de una mujer en este hilo), un poco de orden, ….
En tan solo 4 dias, ha muerto Nokia, ha resucitado Windows, han ganado batallas Apple y Google con iOS y Android, se han vendido mas de 10.000 millones de aplicaciones que nadie usa, …
Esto parece “Star Wars”, el culebrón, y ahora solo falta que llegue “Intel Vader” y le diga a “Luke Meegowalker” … ¡Yo, soy tu padre!
Vamos señores, un poquito de seriedad,
… todos queremos una respuesta, a todos, incluso a mi, nos gustaria estar en posesión de la verdad absoluta, pero si algo me ha demostrado la experiencia, es que, las decisiones precipitadas … ¡suelen ser erroneas!
¿Queremos eso? Yo, ¡NO!
Velneo tiene una papeleta muy dificil , y seguro que todos deseamos que tomen la mejor decisión sobre este tema. Yo también estoy preocupado, aunque no demasiado, … por una razón, en todo este tiempo he visto como la herramienta ya ido evolucionando, despacito y con buena letra, y hasta ahora, a pesar de nuestras opiniones, nuestras diferencias y nuestras preferencias personales, han sido tratadas con profesionalidad y estan siendo atendidas.
Seguro que siempre va a haber alguién descontento, evitarlo es casi imposible, pero creo que las mejores decisiones se tomán con los pies calientes y la cabeza fria. Asi que lo mejor que podemos hacer es dejar que Velneo haga su trabajo, y estudie este tema, no desde la fiebre generada por este foro, sino con decisiones basadas en la lógica y en el estudio de los últimos acontecimientos.
Está claro que esto es una partida de ajedrez donde hay muchos jugadores, y aquel que haga el primer movimiento equivocado, podrÃa quedarse fuera de la partida.
Asi que, dejemos que tomen sus propias decisiones friamente, con el tiempo necesario para ello, y seguro que todos saldremos beneficiados.
¡¡¡ Feliz dia de los enamorados !!!
ene
19
En este hilo del foro, se comentan algunas cosas interesantes, y me gustaria aclarar y dar mi punto de vista
Crear aplicaciones sobre una base de datos existente
Velneo, en su modelo de “Base de Datos Real”, algo que la diferencia de las bases de datos relacionales como MySQL, PostgreSQL, SQLite, Oracle, MS-SQL, tiene muchas ventajas y algunos inconvenientes.
No voy a centrarme en esta ocasión en verificar cual de estas bases de datos obtiene mejores rendimientos, ya que no es el tema que se debate en esta ocasión.
El tema en cuestión, es que cada uno debe valorar las ventajas que les reporta una base de datos y los inconvenientes, y despues, agitarlo todo en una cocktelera, y tomar una decisión al respecto.
Desde que conoci Velazquez Visual, ahora Velneo, una de las cosas que mas me ha gustado, y de las que uno menos suele valorar con el paso del tiempo (quizá por la costumbre), ha sido la refactorización, y la facilidad con que podia realizar cualquier cambio en la estructura de la base de datos, sin tener que preocuparme de nada en absoluto.
Cuando llegue a Velazquez Visual (alla por el 97/98), venia precisamente de SQL (Multibase – Transtools), y aunque la base de datos funcionaba estupendamente en SQL, la empresa dejó de mantener las actualizaciones periodicas que realizaban (semestralmente). Durante casi 3 años estuve, probando otras herramientas, y por fin, en una revista especializada, vi el anuncio de Velazquez Visual, y decidi pedir una demo.
Desde que la instale, me sorprendio la facilidad con que se realizaban las actualizaciones en los datos, y la cantidad de tiempo que me ahorraba en mis actualizaciones a los clientes. Desde entonces, han ido apareciendo muchas novedades, algunas muy interesantes y llega un momento en que incluso podria haber olvidado toda la comodidad que habia ganado.
Cuando Velazquez Visual parecia que iba a desaparecer, volvi a buscar otras herramientas, y de nuevo el mismo problema, despues de evaluar varias herramientas, decidi que no queria perder la comodidad que habia tenido todos estos años.
La presentación de la V7 fue una luz en el camino, y decidi que habia que seguir esa luz.
Si bien es verdad que me he quejado mucho, siempre lo he echo para que Velneo respondiera, con la unica intención de mejorar la herramienta. Y parece que ese cambio se está produciendo, quizá mas lento de lo que todos deseariamos, pero veo como las cosas cambian, para mejor, y eso me gusta.
 Volviendo a lo que nos pedia “Cjribera” en el foro, es cierto que todo el esfuerdo de Velneo esta pensado en su propia base de datos, y aunque el acceso a bases de datos externas, es posible, siempre se echa algo en falta.
Para estos casos, yo he decidido que hay que protestar y pedir y aportar ideas y/o soluciones, porque si no pido lo que necesito, si no me quejo por lo que no me gusta, ¿como van a saber en Velneo mis problemas?
Ahora despues de analizar estas peticiones, estoy pensando que me parecen muy interesantes, pero he querido llegar un poco mas alla, y he pensado, ¿como podriamos tener acceso a otras bases de datos? o dicho ¿como podriamos tener objetos de V7 asignados a tablas de bases de datos externas?
Y he tenido un pequeño “flash”, y he visto una posible solución al problema para poder usar bases de datos externas manteniendo lo bueno de Velneo, la refactorización.
Primero pense, asociar cada uno de los objetos a una “tabla SQL“, formularios, rejillas, busquedas, tubos, procesos, es complicado, cada vez que se produzca un cambio en la base de datos externa, los objetos dejarian de estar enlazados y se producirian cantidad de errores.
Entonces, como solucioarlo …  ¡¡ thinking !!
… y unos minutos despues, una idea,
Podriamos crear “Tablas lógicas“, con estructura similar a las tablas de la base de datos SQL (basicamente copias de las tablas), y asi podriamos asociar los objetos a estas tablas lógicas, manteniendo toda la operatividad que tenemos ahora.
Esta idea, permitiria mantener la refactorizacion entre los objetos de Velneo y las “tablas lógicas”. Cierto es , que si se produce un cambio en la estructura de datos de SQL, deberiamos corregirlo tambien en la “tabla lógica” para que los objetos se adaptasen correctamente, pero en cualquier caso, solo habria que corregir la estructura de campos de la tabla, evitandonos realizar correcciones en todos los objetos.
Luego segui soñando, y por soñar, que no quede…
Ya que tenemos esta “tabla lógica“, porque no tener toda la funcionalidad completa, ¿que quiero decir con esto?,
Pues que, ya puestos, y con las tablas sincronizadas, entre SQL y Velneo, realizar un alta en la “tabla lógica“, o una modificación o una baja, porque no mantener actualizada la tabla SQL, diretamente, ¿no es eso lo que hace ODBC?
Pero en este caso, realizando altas, modificaciones, bajas, o búsquedas directamente con sentencias de Velneo sobre las “tablas lógicas“.
Luego de soñar todo, viene un pajarito y me dice ¿porque te complicas tanto la vida?, todo esto puede ser mas sencillo aún. ¿Como?, y el pajarito me respondio:
A la definición de tablas actual, bastaria con añadir una propiedad “Conector”, que nos permitiera indicar a que base de datos vamos a realizar la conexión: Velneo V7 (interna), a MySQL, a PostgreSQL, a Oracle, y porque no a tablas de V6 con Aplicaciones de V7, etc.
Y de paso, una propiedad más , para establecer los datos de conexión a la base de datos. Y sobre todo, poder cambiar estos datos de conexion en ejecución para poder tener varias instalaciones con la misma estructura de base de datos.
Y ahora me direis, “los pajaritos no hablan”, pero como esto era un sueño, y en los sueños todo es posible. Además, este es mi sueño y yo decido quién habla y quién no, 
Luego me despierto y pienso que ha sido un sueño bonito, y que si lo cuento, es posible que se haga realidad. 
Aqui podeis votar la idea:
Desarrollar directamente sobre bases de datos existentes
P.D.:
Y porque el nombre de “Tabla lógica“, pues sencillamente, porque su funcionamiento seria similar al de las “Impresoras lógicas“, y de esta forma, todos los objetos de V7 quedan asignados a un origen, y ya solo nos queda asociar la tabla lógica a la tabla SQL, de la misma forma que asociamos una impresora lógica a una impresora real instalada en el sistema.
ene
11
Nuestro amigo Héctor González nos plantea una serie de dudas en este hilo del foro:
dudas-sobre-varias-funcionalidades
Y aprovecho este post para responder a la tercera de sus consultas con un poco mas de detalle.
Planteamiento:
¿Es posible realizar busquedas donde el indice pueda ser varios valores posibles? ¿Algo como el INLIST o el EXIST en SQL?, hasta ahorita lo hemos resuelto con varias comparaciones OR. Queremos eralizar consultas como ¿Dame los movimientos contables de los clientes que se encuentran en una lista dada?
Solución:
Para solucionar este problema vamos a usar 2 Cestas, que ya podeis ir creando:
- Una, para la tabla de clientes, en ella guardaremos los clientes de la lista.
- Otra, para la tabla de movimientos, en ella guardaremos el resultado.
- También necesitamos una búsqueda de movimientos de UN cliente, con un indice CLIENTE por parte izquierda
Muchos ya estareis imaginando el resultado, es muy sencillo.
Ahora que ya tenemos los clientes en la primera cesta, solo tenemos que crear un proceso, el origen de este proceso da igual, dependera de donde lo useis, pero no influye en el resultado.
En el proceso, “Procesamos la cesta de CLIENTES” y recorremos la lista en modo “solo lectura”, y en cada uno de los registros de los clientes, ejecutamos una “Busqueda” en la tabla “movimientos”.
Para cada registro de la cesta de clientes, asignamos el ID del cliente a una variable, y mediante las sentencias del “Manejador de objetos”, asignamos la variable a la búsqueda y ejecutamos la busqueda de movimientos de un cliente.
El resultado de esa búsqueda, lo agregamos a la otra cesta que habiamos definido, y vamos agregando todos las listas de movimientos a la “Cesta de MOVIMIENTOS” hasta finalizar la lista de clientes.
Una vez finalizada esa parte, ya solo nos queda ver el resultado, como:
“Procesamos la Cesta de MOVIMIENTOS” y “Añadir lista a la salida”
Ahora solo tienes que definir una ACCION que ejecute el proceso y retorne una rejilla para mostrar el resultado.
Como podreis imaginar, ¡yo tambien lo estoy imaginando!, y deberia funcionar. Pero, a estas horas, no tengo ganas de abrir vDevelop ni tiempo para probar si el resultado es correcto.
Pero aunque puedo haber olvidado algún detalle, lo importante es captar el concepto.
¿Lo pillas?
dic
23
Hace unos dias, en un artÃculo anterior, en el que comparabamos V6 y V7, no para criticar, sino para ver las diferentes formas de llegar a los mismos resultados en determinadas operaciones:
Encuentra las diferencias entre V6 y V7
Prometi a Miguel un ejemplo para ver como se realizaba un ejemplo para procesar varios elementos de una rejilla marcandolos con check como el de la imagen.
En V6 este ejemplo se podria realizar de 2 formas:
- Con una rejilla multiseleccion y una toolbar, creando un proceso con origen LISTA y recorriendo los registros para procesarlos y ejecutando el proceso desde la toolbar.
- Con una rejilla incrustada en un formulario y un boton que ejecuta el proceso para recorrer los rejistros seleccionados.
Como la misión no es desarrollar el ejemplo en V6, vamos a continuar y a ver como realizarlo en V7.
Y en V7 necesitariamos lo siguiente:
Un formulario, en el ejemplo hemos incluido 2 controles objeto, que muestran 2 rejillas de 2 tablas.
El ejercicio es conseguir procesar varios registros de la rejilla inferior y procesarlos para subirlos a la rejilla superior, pulsando el boton “INCLUIR”.
Para ello necesitamos crear un evento en el formulario como el siguiente:
En el se procesan los registros seleccionados de la rejilla inferior y recorremos la lista, realizando las operaciones necesarias en cada uno. Al finalizar el proceso ejecutamos las sentencias de “Interfaz: Recalcular control()” , para asegurarnos de que las rejillas se actualizan correctamente para reflejar los cambios.
Ahora ya solo nos queda incluir el boton y asignarle el evento anterior
Un ejercicio muy sencillo, cuando se sabe, claro.
dic
22
:O
Si, asi es, es la cara que se me quedo ayer cuando vi como, por primera vez, Velneo hace publica una noticia con la suficiente antelación a la publicación oficial de la nueva versión 7.6
Todo empezo con el anuncio en Facebook, que nos dejo perplejos, nuestro arquitecto Juan Muñoz, se tomaba un descanso tras acabar la versión 7.6, mientras sus compañeros se dedican a documentar las mejoras implementadas.
Notición: La 7.6 esta finalizada, comienza la fase de documentación.
Por si fuera poco, esa misma tarde David Gutierrez nos anuncia oficialmente las novedades que incluye la nueva versión.
Mas sorprendente aún, , nos anuncia que “algunas” de las ideas han sido incluidas en la nueva versión y me pregunto ¿cuales?, estoy intrigado, quién sera el afortunado. Porque parecen haberse creado 2 bandos entre los que apoyamos la idea de “INTRO-TAB” y los que apoyan la idea de “Android”.
Esta claro, que, no todos podemos estar igual de satisfechos, ya que hay opiniones para todos.
Solo hemos tenido que esperar un dia para saber la solución, Velneo nos ha vuelto a sorprender haciendo publicas la nueva situación de las ideas que los usuarios han votado.
Y a pesar de los problemas que puedan presentarse, debido a la multiplataforma, no me queda mas remedio que quitarme el sombrero, por el esfuerzo realizado por el equipo de Velneo para solucionar este problema. ¡¡Chapeau!!
La segunda idea, tambien ha sido estudiada, y eso es mucho, y muy importante, porque, a pesar de que no este claramente definida la postura final, el simple hecho de que hemos sido informados, ya es un avance muy importante.
Y no voy a dudar de su palabra, de que intentarán hacerlo lo mejor posible, ¡¡Gracias por la información!!
Y no menos importante, una noticia de la que ya habiamos sido informados en la presentación del 12 de noviembre, se trata de la implementación de “Aceptar sin cerrar formulario”, con alguna mejora más.
Pero esto, no de beria ser visto como un problema por aquellos que solicitaron otras ideas como primordiales:
porque una vez conseguido nuestro proposito principal, ¿que nos impide apoyar a los que solicitaron estas ultimas ideas?.
Al final va a resultar que noticias como estas: “Desde mi punto de vista” y “La importancia de TAB o INTRO” y debates como este, “Enter o Tab, prioridad máxima” si son importantes, y digo yo,
No se trata de estar en dos bandos, unos contra otros, se trata de definir prioridades, y personalmente, conseguida la priodidad que teniamos, nuestro apoyo puede convertirse en nuevos votos para el resto de ideas, para que sean tenidas en cuenta en un futuro breve.
A Velneo, gracias, por hacernos sentir, que de verdad las cosas estan cambiando.
No se si estar mas agradecido por las novedades que nos esperan tras las navidades, o por el simple hecho de haber sido informados.
En cualquier caso, es uno de los mejores regalos que nos podian hacer.
¡¡¡GRAAAAAAAAACIIIIIIAAAAAAASSSSSSS!!!
dic
20
Nuestro amigo sat.sbinario plantea el siguiente problema en el foro de V7
Preocupación con el rendimiento con número de registros elevado y optimización
en el que expone lo siguiente:
Hola a todos:
La situación es esta. Tabla con 40 campos (2 de ellos singular de plural por Ãndice), unos 10 Ãndices y 180000 registros.
He notado que el rendimiento de la aplicación cuando se trabaja con esta tabla decae notablemente. Por ejemplo, una rejilla que muestra todos los registros (resultado de una búsqueda), “se ve” en pantalla mientras la carga cómo va refrescando los datos, en especial los resueltos a través de los punteros singular de plural. Además cuando utilizas algún localizador asociado a la tabla, tienes tiempos de espera notables, que incluso provocan la rotura del vClient si no eres suficientemente paciente.
Esto nunca me habÃa pasado en v6, asà que lanzo varias preguntas.
¿Se debe a los punteros singular de plural? ¿A los componentes visuales? ¿Qué aspectos intervienen en estos tiempos de espera? ¿Optimización? ¿Alguna experiencia con número de registros elevados?
Un saludo y gracias.
Y despues de varias respuestas en el mismo hilo del foro se llega a la conclusion de que el problema esta en los “Punteros singular de plural”. Y la verdad, considero que es un problema muy puntual, para casos especiales.
Como ya sabeis, yo suelo protestar mucho donde otros no protestan, pero como me gusta llevar la contraria a todos, , donde los demas se quejan, yo busco soluciones, asi que analicemos el planteamiento y veremos la solución:
Planteamiento:
- La tabla tiene “muchos campos”
- La tabla tiene varios “punteros singular de plural por indice”
- La tabla tiene 180000 registros, pero podria tener más.
Problema:
Ya hemos identificado que el problema son los “punteros singular de plural por indice”
Solución:
A la vista de estos parametros tenemos varias soluciones posibles:
- El problema son los “Punteros” pues una solución sencilla es “Quitar los punteros”, , creo que es la más fácil, la mas sencilla de implementar y la que mejor soluciona el problema. Ahhhhhhhhh, vale, ¡que no se puede hacer eso!,
 , pues vamos a buscar otra solución.
- En el foro se aporta una solución que también es valida, dejar los punteros en la tabla, pero quitarlos de la rejilla. Es una buena solución, pero que pasa si necesito mostrar columnas a través de los punteros y no puedo eliminarlos, esta solución tampoco es valida.
- Olvidemos el problema principal, que parecen ser los “Punteros” y centremonos en el resto de parámetros de la ecuación. Haber, para que necesito mostrar 180000 registros, acaso tengo que memorizarlos, , ¿necesito verlos todos? si falta uno, o faltan 1000 registros, ¿te vas a dar cuenta?. Pues ahi tienes la solución, prepara un paginador y muestra los registros de 100 en 100 o de 5000 en 5000 y veras como la velocidad aumenta considerablemente. Ademas, antes de mostrar cantidades indecentes de información, deberiamos pensar todos en el ahorro economico (si, economico), porque vamos a utilizar las aplicaciones con moviles, y las compañias van a cobrar por volumenes de transmisión de datos, y de esta forma, además, matamos 2 pajaros de un tiro (ahorramos dinero a nuestros clientes, beneficiandoles a ellos, y reducimos su factura de consumo telefónico, perjudicando al operador de telefonia).
Piensa en verde, porque ahorrar es sano, sobre todo para el bolsillo, … y en estos tiempos que corren, más.
Y ahora me direis algunos, … ¿y como se hace un paginador en V7? … vale, vale, lo preparo y otro dia os lo cuento.
dic
15
Para los que venimos de V6, el cambio a V7 puede ser mas sencillo que para otros desarrolladores que se inician y tienen que cambiar totalmente “El Chip”, pero ese camino de “rosas” que debemos recorrer los mas avanzados en este aspecto, tambien esta lleno de “espinas” que debemos evitar.
Aqui voy a esponer algunas de las principales diferencias que hay entre V6 y V7, y esta vez no para criticar, sino para que los usuarios de V6 no pierdan gran cantidad de tiempo en averiguar esas pequeñas “tonterias” que nos amargan el dia
- Una de las diferencias entre V6 y V7 es la forma en que podemos sumar y restar dias a una fecha determinada. En V6 podiamos hacerlo sumando directamente los dias a la fecha “fHoy() + 10″ o “fHoy() – 30″ en la expresión, para obtener la fecha resultante. Ahora debemos hacerlo mediante la función “AddDays( currentDate() , 10)” para sumar y “AddDays( currentDate() , -30)” para restar
- Otra pequeña “gran” diferencia es la edición de campos en formularios, mientras en V6 un campo numérico o alfanumérico se podia editar con el mismo EDIT, en V7 necesitamos un control de “Edición” para campos alfanuméricos y un “Microscroller” para campos numéricos, ya que si ponemos un campo numérico en un “Edit” se convierte en texto automáticamente, al menos cuando se trabaja con variables locales.
- No busques las funciones de NumeroEnLetras() y FechaDiasFijos() porque en V7 no exiten y te las tienes que definir tu mismo. Y la función para calcular el DC de un número de cuenta bancario, tampoco está. Entiendo que estas funciones no han sido incluidas debido a la internacionalización de la herramienta y a que son funciones que varian dependiendo del idioma o pais, aunque esta excusa no es aplicable a la función FechaDiasFijos().
- Tambien han desaparecido todas las funciones que habia en V6 en el grupo de Códigos de Barras.
- En V6 disponiamos de una función de proceso “ExtraerDato()” para parsear cadenas de texto y tenias que copiarla en todos los mapas donde era necesaria. En V7 no la busques, tenemos una función del sistema que realiza la misma tarea de manera mas eficiente: “StringSection()”
- En V6, para indexar un indice condicionado, necesitabamos obligatoriamente un campo “Check” o “Booleano” para usarlo en la condición del indice. En V7 podemos indicar la exprexión directamente sobre la condición del indice, si bien esto puede penalizar el rendimiento de la base de datos.
- Otra diferencia importante, es la conexión entre vClient y vServer en las versiones V6 y V7, ya que mientras V6 consume una única licencia de usuario por maquina (aún teniendo varias aplicaciones en ejecución), en V7 se consume una licencia de usuario por cada aplicación o instancia que se ejecuta (incluso en la misma maquina), lo cual es un inconveniente, ya que se necesitan muchas mas licencias en V7.
- En V6, para cambiar la clave de acceso del usuario, se hace desde el menu de vClient directamente. En V7 es necesario crear una accion “Archivo: cambiar contraseña de usuario” y ejecutar dicha acción desde algun lugar de la aplicación.
- Jorge Velasco, me dice que no puede usar mas de 10 parametros en las funciones de V7, mientras que las funciones de V6 no tienen limite de parametros (aparentemente) (editado el 16-dic-2010) y esta es una la solución que yo utilizo para resolver este problema: Parametros en funciones.
Espero que podamos mejorar este articulo entre todos y añadir todas aquellas cosas que puedan llevar a error o confusión.
De momento dejo aqui una pequeña lista, pero ire completandola a medida que vayan apareciendo esos pequeños detalles.
dic
13
Nuestro amigo Miguel nos propone una solución al uso de variables en memoria, y dice textualmente:
Pues bien despues de volverme loco por la lentitud de una aplicacion que en local me va de vicio pero en la nube no, resulta que parte del problema era la modificacion de variables globales em “memoria” tarda un huev… en modificarlas no entiendo el porque pero bueno. El hecho es que si la variable se va a mover poco pues la modificas y ya esta, pero si la vas a mover mucho y estas en la nube creas una tabla en memoria hay te creas unos campos para variable numerica otro alfabetica, booleana etc… dos funciones una para escribir en un reg N el valor y otra para leer el valor y en vez de modif variables grabas y lees la tabla es como 5 veces mas rápido que modif variable y se nota un huev….
Este es el hilo oficial:
¿Variable global en memoria o tabla en memoria?
Y despues de leer este hilo del foro, empece a pensar en publicar un pequeño articulo sobre este tema, sobre la realización de un ejemplo tal y como Miguel, el autor de este hilo, nos propone el uso de una tabla para almacenar las variables globales en memoria para mejorar el rendimiento de este tipo de variables.
Tal y como el propone, el ejemplo es sencillo de resolver. Solo necesitamos:
- Una tabla “en memoria”, con los campos para almacenar los identificadores de las variables y sus valores
- Una función para guardar y modificar los valores de esas “variables”
- Una función para leer el contenido de las “variables”
Ya esta, con esto, tan sencillo y básico, podemos mejorar el rendimiento del uso de variables en memoria y conseguir que sean hasta 5 veces mas rápidas (y vamos a creer lo que nos dice, ya que en el momento de escribir este articulo aún no he podido realizar pruebas para poder verificar dicha afirmación).
Pero, tras empezar a escribir el articulo, me rondaba algo por la cabeza, algo me decia que esto no podia quedar ahi, que tenia que haber más, una solución sencilla y brillante, de las que cuesta llegar a averiguar, y cuando llegas a dar con la solución, piensas, ¿porque no se me habrá ocurrido antes?
Y luego pensé, porque no podemos aplicar esta misma solución para las variables globales “en disco” y la solución es mas sencilla aún. Si ya hemos realizado el ejemplo anterior, y para ello hemos utilizado una tabla en memoria, porque no hacer lo mismo con una tabla “en disco”.
Porque debemos preguntarnos, si ha funcionado con variables en memoria y ha sido mas eficiente, ¿porque no probar con variables en disco?
Además, ya habiamos resuelto un problema importante con variables de tipo array, recuerdas, y si aplicamos esta misma lógica, el ejercicio quedaria resuelto tanto para variables de tipo array en memoria, como para variables de tipo array en disco.
dic
9
Como ya habia indicado en el artÃculo anterior, voy a seguir indicando algunas nuevas sugerencias para la próxima versión, y de nuevo las voy a exponer aqui, porque no puedo exponerlas en el foro de ideas.
Continuación de … Mejoras para próximas versiones y de Marchando una de ideas!
Y una observación, que me gustaria dejar clara aunque se que no sirve de nada, pero lo tengo que decir:
Que los Nivel-1 no tengamos derecho a exponer ideas porque “no podemos votarlas” me parece un atraso, pero es lógico, “no pagamos” y por tanto no tenemos acceso de dicho foro.
Deducción lógica, los niveles-1 no podemos tener ideas, somos torpes y nuestro coeficiente intelectual es el de una gallina.
Que los Nivel-2 y superior, solo tengan 10 votos, esta bién, pero esto siginifica que solo pueden votar 10 veces, y siguiendo este razonamiento, significa que si ya han utilizado 5 votos para “votar” las ideas de otros, solo disponen de 5 votos para exponer sus propias ideas.
Deducción logica según este razonamiento: cuando un Nivel-2 o superior vota 10 veces, pierde toda su capacidad intelectual, y se vuelve por tanto incompetente, es decir, cambia a nivel-1, lo que deja su nivel intelectual a la altura de las gallinas
Esta teoria es una versión de la investigación realizada por cientificos rusos con las arañas, en la cual llegaron a la conclusión de que al cortar todas las patas a una araña, esta se quedaba “sorda”.
Si alquien quiere mas información acerca de esta investigación y de otras similares de las que ni siquiera WikiLiqs tiene conocimiento, no tenemos inconveniente en enviarselas mediante comunicación privada, y sin respondabilidad por las posibles represalias que pudieran sufrir por parte de la “T.I.A.”
Y como, a pesar de todo, estos razonamientos no me parecen nada lógicos, voy a exponer una idea, tremendamente ILOGICA y seguramente … iba a decir una ¡BURRADA!, pero la idea la dejo caer:
Disponemos de una de las mejores herramientas para desarrollos con bases de datos, y tenemos un FORO que es una castaña pilonga, “al menos el de V7″ (y por favor, no me refiero a la comunidad, me refiero a la funcionalidad del foro), mucho mejor es el de V6, pero razones habrá para esto y no las discuto.
Y tenemos un “FORO DE IDEAS” que es mejor que el de antes, pero sigue siendo “chungo”.
Y lo que “NO” tenemos, es un foro de ideas realizado con “V7″ donde podriamos hacer, opinar, exponer ideas, votar (quien tenga permiso, claro) y lo mas importante, adaptarlo a las necesidades de la comunidad, asi, “por los pinrreles”. Y nos conformamos con unas “churres” de aplicaciones, porque “no queremos reinventar la rueda” aunque eso significa seguir en la prehistoria.
Deberia caersenos la cara de verguenza, decir que con esta magnifica herramienta que nos une, y seguimos usando los recursos de las “obsoletas” bases de datos relacionales.
Ademas, ahora incluso los Nivel-1 tenemos acceso a vWebClient, si mal no recuerdo, y eso “NOS DEVOLVERIA NUESTRA INTELIGENCIA” y el derecho a poder “IMAGINAR” / “TENER IDEAS” de las que se podrian beneficiar los compañeros “Intelectualmente mas capacitados, aunque de inteligencia limirada (solo 10 ideas por barba)”
Aqui dejo las sugerencias para quien las quiera escuchar:
- Función para saber el tipo de contenido de una variable local, variable global o campo de una tabla. Eso es, una función que permita saber si una variable es numerica, alfanumerica, booleana, fecha, hora, etc. Y si ademas, pudieramos saber si tiene “Signo” y el numero de “Decimales” o la “Longitud” en el caso de variables/campos alfanumericos, mucho mejor.
- Función para saber la resolución de la pantalla que se esta utilizando en cada momento por el S.O. Esta función nos retornaria la resolución 800×600, 1024×768, etc y asi podriamos decidir si tenemos “suficiente pantalla” para mostrar determinados objetos o combinacion de objetos.
- Funciones para el calculo de codigos de barras, tanto en el Asistente de formulas, como en los informes para poder imprimir los códigos de barras.
- Un inspector de errores que nos revise todos los proyectos de una solucion y nos indique, cuales de los pryectos tienen errores, para poder revisarlos uno a uno con mas detalle. En soluciones grandes, es complicado tener que revisar los proyectos uno a uno y puedes olvidar siempre alguno. Ademas hay que revisarlos con frecuencia cuando se estan modificando constantemente, lo que hace mas dificil aun mantener limpio el desarrollo.
- Inspector de objetos no usados de un proyecto y/o solución. Creo que no necesita mayor aclaración.
- Inspector “Donde se usa” de campos e indices de las tablas. Ahora solo funciona a nivel de identificador de tabla.
- Posibilidad de poder crear el objeto BUSQUEDA en el proyecto de datos (aunque SIN formulario de entrada de datos, por supuesto).
- Posibilidad de Tubos de Ficha y de Lista en los proyectos de datos (tambien SIN formularios de peticion de datos)
- En el control objeto de un formulario, ahora es necesario crear un proceso para lanzar una busqueda que retorna una rejilla , informe o casillero. Deberia permitirse lanzar directamente una busqueda, y asi evitariamos crear el proceso solo para llamar a la busqueda.
- En la imagen siguiente, podemos ver como al intentar “Dar permiso” a un grupo de usuarios a una aplicación, no podia ver la aplicación porque no aparecia en pantalla y por tanto, complicando la historia para solucionarlo. La solución, al final, dar permiso a todas las aplicaciones y eliminar, una a una las que no debian aparecer, con lo que eso supone, posibles errores, etc…
También quiero agradecer a Velneo, que al margen de estas criticas, es cierto que ya en varias ocasiones, a escuchado las sugerencias que desde este blog se han reclamado y ha dado solución a los problemas planteados, y aqui dejo el ejemplo: Mejorar el rendimiento , que si mal no recuerdo, se solucionó en la versión 7.4.1, tan solo un mes despues, ya que el error fue reportado despues de la salida de la versión 7.4. Gracias, esto también hay que tenerlo en cuenta, y dice mucho en favor de Velneo.
¡VOLVERE … !
… con más ideas
… si mi coeficiente intelectual de gallina me lo permite.
|
