Anónimo
Consulta en vfp 6
- Hola, programo en vfp6, pero me gustaría programar en un lenguaje que este vigente en un futuro, que lenguaje me recomiendas.
- Sigo teniendo problemas de mensaje de set attemp to esc, básicamente este problema se da cuando los usuarios están en un grid a pesar que cada usuario trabaja con registro diferentes (facturas diferentes), a pesar que ya grabe el ejecutable en cada PC y lo que hago es solo usar las tablas libres del cpu que actúa como servidor (uso mi aplicativo con solo tablas libres). Esto obliga al usuario que esta en el grid a salir del grid para que el otro usuario pueda seguir con su trabajo.
- ¿Me recomiendas trabajar Postgres Sql con vfp6 y dejar de lado los DBFs?,, te digo que me siento cómodo con los DBFs son tan prácticos para hacer modificaciones ya que todo lo tengo en una memoria USB y luego le paso el KONSIXE, pero estos DBFs son lentos cuando se hacen consultas en las tablas, me dicen que con un SQL SERVER, MYSQL, POSTGRES seria más rapido, ¿de hecho descarto el SQL SERVER por costos pero estará bien que cambia mi aplicativo para trabajar con Postgres?, ya que me dicen que es mejor que Mysql
Gracias
- Sigo teniendo problemas de mensaje de set attemp to esc, básicamente este problema se da cuando los usuarios están en un grid a pesar que cada usuario trabaja con registro diferentes (facturas diferentes), a pesar que ya grabe el ejecutable en cada PC y lo que hago es solo usar las tablas libres del cpu que actúa como servidor (uso mi aplicativo con solo tablas libres). Esto obliga al usuario que esta en el grid a salir del grid para que el otro usuario pueda seguir con su trabajo.
- ¿Me recomiendas trabajar Postgres Sql con vfp6 y dejar de lado los DBFs?,, te digo que me siento cómodo con los DBFs son tan prácticos para hacer modificaciones ya que todo lo tengo en una memoria USB y luego le paso el KONSIXE, pero estos DBFs son lentos cuando se hacen consultas en las tablas, me dicen que con un SQL SERVER, MYSQL, POSTGRES seria más rapido, ¿de hecho descarto el SQL SERVER por costos pero estará bien que cambia mi aplicativo para trabajar con Postgres?, ya que me dicen que es mejor que Mysql
Gracias
1 respuesta
Respuesta de jsam
1
A mi me ha resultado bastante efectivo el llenar las Grids por medio de consultas SQL, de esta manera se crea un cursor en memoria volátil, con esto se crea una copia en cada equipo evitando bloqueos. En las propiedades del Grid, la propiedad RecordSourceType debes establecerla a 4 - Sentencia SQL. Debes establecer el numero de columnas a visualizar y estas deben ser las primeras que se mencionen en la sentencia SQL, la cual puedes asignar a la Grid por medio de la propiedad RecordSource="Select ...". En esta sentencia SQL puedes incluir el identificador único de cada registro (Campo Key) el cual puedes usar para Actualizar tu tabla.
La idea es que la tabla original permanezca abierta el menor tiempo posible para reducir la incidencia de los bloqueos. De este modo la tabla solo será abierta cuando se realice la consulta para llenar el Grid y cuando actualices los datos. Todo esto implica un poco más de código, pero tienes más control sobre los bloqueos.
Por otro lado, definitivamente trabajar con DBFs ya no es funcional, por diferentes motivos este tipo de tablas ya no es muy funcional, actualmente yo trabajo con Microsoft SQL, pero como bien dices es muy caro, la opción es el software con licencias libres, el más utilizado es MySQL, pero me inclino más por Postgre SQL, más que nada por su variedad de tipos y la versartilidad que hay en los triggers, además de que con él no tendrás problemas de bloques, ya que Postgre los maneja perfectamente.
En la organización en la que yo trabajo, desde antes ya utilizaban tecnologías de Microsoft (VB, SQL) por lo que me he tenido que adentrar más en esto y descuidar otros aspectos, entonces no te podría ayudar con Postgre, ya que no estoy muy familiarizado con el.
También te puedo decir que me he conectado desde VFP hacia Microsoft SQL y trabaja muy bien, con muy buena velocidad, puedes aprovecharte de esto ya que creo que cuentas con algunos conocimientos de VFP y con esto puedes optimizar tus aplicaciones. Cabe mencionar que no es la única conexión que puedes lograr con VFP, también te puedes conectar con otros administradores de bases de datos.
Me despido, espero haber sido de ayuda. No lovides finalizar la pregunta.
La idea es que la tabla original permanezca abierta el menor tiempo posible para reducir la incidencia de los bloqueos. De este modo la tabla solo será abierta cuando se realice la consulta para llenar el Grid y cuando actualices los datos. Todo esto implica un poco más de código, pero tienes más control sobre los bloqueos.
Por otro lado, definitivamente trabajar con DBFs ya no es funcional, por diferentes motivos este tipo de tablas ya no es muy funcional, actualmente yo trabajo con Microsoft SQL, pero como bien dices es muy caro, la opción es el software con licencias libres, el más utilizado es MySQL, pero me inclino más por Postgre SQL, más que nada por su variedad de tipos y la versartilidad que hay en los triggers, además de que con él no tendrás problemas de bloques, ya que Postgre los maneja perfectamente.
En la organización en la que yo trabajo, desde antes ya utilizaban tecnologías de Microsoft (VB, SQL) por lo que me he tenido que adentrar más en esto y descuidar otros aspectos, entonces no te podría ayudar con Postgre, ya que no estoy muy familiarizado con el.
También te puedo decir que me he conectado desde VFP hacia Microsoft SQL y trabaja muy bien, con muy buena velocidad, puedes aprovecharte de esto ya que creo que cuentas con algunos conocimientos de VFP y con esto puedes optimizar tus aplicaciones. Cabe mencionar que no es la única conexión que puedes lograr con VFP, también te puedes conectar con otros administradores de bases de datos.
Me despido, espero haber sido de ayuda. No lovides finalizar la pregunta.