SQL SELECT

[JCReyna]

Buenos días

Estoy cambiando de bases nativas de vfp con seek y append a comandos sql sobre las mismas bases nativas. La idea es en un futuro pasar todo a cualquier otro manejador de bases de datos.

Tengo una tabla con un campo referencia C(15),  que tienen tres registros con los sig. valores:

referencia = 'abc'

referencia = 'abcx'

referencia = 'abcxx'

al ejecutar select * from tabla where referencia =  'abc'  me regresa los tres registros.

al ejecutar select * from tabla where referencia == 'abc' regresa solo registro correcto.

al ejecutar select * from tabla where referencia = 'abc+12espacios' regresa solo registro correcto.

Como la idea es que las sentencias sql funciones para cualquier bases de datos y al parecer el operador '==' solo aplica para VFP dado que no he encontrado en google referencias a este operador para otras bases de datos.

Ya intente con alltrim(referencia)='abc',  ltrim(rtrim(referencia))='abc' y ambos me regresan los tres registros.

Con el SELECT como quiera, por codigo puedo analizar los registros regresados y tomar solo los que correspondan, pero el DELETE y el UPDATE si son un problema.

Que tengo que hacer para que el operador '=' me regrese solo el registro que corresponde?

Agradezco de antemano cualquier comentario que me puedan dar.

[Zarlu]

Buenos días Carlos!

Prueba con el parámetro Like  y los operadores "%" y "_". Revisa la ayuda de VFP

Select......WHERE .... like "abc"

Select......WHERE .... like "abc_"

Select......WHERE .... like "abc%"

Yo estoy iniciando con Mysql, no sé de otros motores, pero con mi insípida experiencia te puedo decir que como sea alguna modificación habrá de hacerse cuando pases a motores.

Pero si es muy recomendable usar comandos SQL en VFP en la medida de lo posible.

Suerte

zarlu

Chetumal, Quintana Roo, México

[Esteban Herrero]

Hola...

Para qué tomarse ese trabajo, lo q te convendría es directamente es hacer pruebas en algún motor, cualquiera el q mejor te venga en gracia, cualquiera q elijas es muuuuuucho mejor q continuar con DBF.

En fin es una sugerencia, no perder tiempo con los dbf.

Saludos

--
Blog de la Comunidad Visual FoxPro en Español http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/0303dfb1-1e5a-4132-b00a-8713dc864ce0n%40googlegroups.com.

[RS “Ricardo de Stgo”]

LO que estas haciendo ya lo realice hace bastante tiempo y para algunos clientes pequeños funciona perfecto, además que ya no es necesario abrir las tablas con use  tabla index indice  (los select update insert delete se encargan de hacer eso) y además no se corrompen los índices .

Para la consulta puntual prueba con lo que te propone zarlu  

Muchas veces puebo el Select directamente en el ms management Studio directo sobre la BD y luego lo copio y lo llevo a VFP 

Y te recomiendo que uses la libreria foxyDb para prescindir definitivamente de las dbf. 

Guia Rapida – Guardar o Deshacer Cambios – FoxyDb (wordpress.com)

[mpulla]

Hola JCReyna.

SET ANSI ON

Saludos.

Mauricio

[JCReyna]

Gracias a todos por sus comentarios

Zarlu, intente lo del LIKE pero me regresa todos los registros.

Intente completando el valor del campo a buscar con espacios a la derecha  hasta completar la longitud del campo y así si me regresa solo el registro que requiero.

[JCReyna]

Gracias mpulla

SET ANSI ON soluciono el problema

[Oscar Bonet]

Si el campo es varchar o char el comportamiento varia.

Yo utilizo el campo varchar en el motor sqlserver para que me traiga tal cual como indica la condicion deseada.

Atentamente,

Oscar G. 

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/def7f274-ee0d-4bee-83b7-6b0cca742c67n%40googlegroups.com.

PBX: (+57) 601 4187884 
Móvil: (+57) 3156497484, 3182932952 y 3182954688

Para recepción de facturas electrónicas de proveedores enviar al correo electrónico: e-facturas@cialta.com

Para el envío de notificaciones de aceptación o rechazos de facturas emitidas por Cialta, enviar al correo electrónico: facturasclientes@cialta.com 

---

INFORMACION IMPORTANTE PARA CLIENTES Y PROVEEDORES - GRANDES CONTRIBUYENTE DISTRITALES:
LA COMPAÑIA INTERNACIONAL DE ALIMENTOS AGROPECUARIOS CIALTA S.A.S. con Nit.830046757-6 informamos que según la resolución No.DDI-023769 del 29 de noviembre del 2021 que hemos sido calificados como GRANDES CONTRIBUYENTES DISTRITALES a partir del 1 de enero de 2022. 

---

FACTURACION ELECTRONICA:
De conformidad con el decreto 2242 de Noviembre de 2015, nuestra Compañía implementó la Facturación Electrónica y según comunicado 100202211-410 del 29 de Junio de 2018 emitido por la DIAN, inició a partir del 1 de diciembre de 2018 para la emisión de la factura electrónica; en consecuencia, hemos destinado la cuenta de correo electrónico: e-fac...@cialta.com para recepción y emisión de facturas electrónicas.

---

HABEAS DATA - PROTECCION DE DATOS PERSONALES
Habeas Data: La Compañía Internacional de Alimentos Agropecuarios CIALTA S.A.S. cumple con los requerimientos de la Superintendencia de Industria y Comercio de Colombia sobre el manejo de información de datos personales, lo cual implica tener políticas claras de tratamiento de Base de Datos que usted puede consultar haciendo clic en: Políticas Habeas Data
Si desea tener más información sobre el particular, puede escribirnos al correo habea...@cialta.com

[Miguel Antúnez]

Hola JCReyna,

Te recomiendo probar un gestor de base de datos moderno. En mi caso, sugiero SQL Server, ya que es mi especialidad y tengo un amplio dominio de esta herramienta. SQL Server ofrece ventajas significativas en comparación con los archivos DBF en muchos aspectos, tales como:

• Seguridad: Proporciona robustas características de seguridad, incluyendo cifrado de datos y autenticación avanzada.
• Integridad referencial: Garantiza la coherencia de los datos mediante restricciones y reglas de integridad.
• Rendimiento: Ofrece un rendimiento superior con optimizaciones para consultas y transacciones.
• Escalabilidad: Facilita el crecimiento de la base de datos sin perder eficiencia.
• Alta disponibilidad: Incluye opciones de replicación, clustering y recuperación ante desastres.
• Herramientas de administración: Cuenta con herramientas avanzadas para la gestión, monitoreo y optimización de bases de datos.
• Compatibilidad: Soporta una amplia gama de aplicaciones y servicios, integrándose perfectamente con otros productos de Microsoft.
• Versiones adaptadas a tus necesidades: SQL Server dispone de diferentes versiones, incluyendo opciones gratuitas, de desarrollo y comerciales, permitiendo elegir la que mejor se adapte a tus requerimientos.

SQL Server es una plataforma robusta y en constante evolución, que te permitirá trabajar de manera más eficiente y segura. No dudes en contar conmigo para cualquier consulta o asistencia que necesites.

Saludos cordiales,

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/dd7fc368-f8e3-4f7c-a881-e8cdbddbe2b8n%40googlegroups.com.

--

mant...@gmail.com
https://mantunezc.blogspot.com/

https://www.youtube.com/vfpsqlperu

https://www.linkedin.com/in/mantunezc/

[Esteban Micossi]

Hola JCReyna

Proba con esto:

select * from mitabla where subs(referencia,1,3)='abc'  ---> te devuelve únicamente las que contienen los tres primeros lugares = 'abc' desde el lugar 1 hasta el lugar 3
select * from mitabla where subs(referencia,1,4)='abcx'  ---> te devuelve únicamente las que contienen los cuatros primeros lugares = 'abcx' desde el lugar 1 hasta el lugar 4
select * from mitabla where subs(referencia,1,5)='abcxx'  ---> te devuelve únicamente las que contienen los cinco primeros lugares = 'abcxx' desde el lugar 1 hasta el lugar 5
Por supuesto esto es puntual, salvo que pongas como variables las posiciones de inicio y final por ejemplo 

select * from mitabla where subs(referencia,x,y)='abc'  ---> Para x=1 ; y=3

Ok?. saludos.

[JCReyna]

Gracias Esteban por tu comentario

El problema es que tengo para el proveedor '0001' la factura 'A12' y la factura 'A123'

Quiero borrar la factura 'A12' pero al hacer un delete from tabla where proveedor = '0001' and factura = 'A12' me borra 'A12' y 'A123'

Lo mismo pasa con el select, me muestra ambas facturas.

Como me recomendó MPULLA, si pongo SET ANSI ON, funciona correctamente.

Viendo la documentación de SET ANSI,  esta indica que completa del campo con espacios a la derecha hasta el total de caracteres definida para el campo, en este caso factura C(15).

En este momento estoy actualizando de tablas nativas de vfp con seek y append a tablas nativas con comandos sql.

En un futuro, cuando tenga actualizado todo el sistema con comandos sql  quiero migrar de bases nativas a un motor de bases de datos sql.

Como no estoy seguro que SET ANSI ON funcione con otros motores de bases de datos sql, lo que estoy haciendo es que a  las variables que van en el WHERE, por medio de PADR(VARIABLE,15,' ') le agrego los espacios en blanco y así funciona correctamente.

Saludos

[Ivan Martinez]

Mira Set exact on

Ivan Martinez von Halle 

--
Blog de la Comunidad Visual FoxPro en Español http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/98218f67-df93-49d0-91fa-48c86f3811aan%40googlegroups.com.

[Antonio Meza]

Te comento que SET ANSI solo va a funcionar dentro de VFP, cuando trabajes con un servidor de base de datos no se vera afectado, incluso tus Where que usas para tablas nativas en su mayoría tampoco te van a servir, ya que muchas funciones de VFP no son reconocidas por los servidores de bases de datos.

Me uno al concejo que te dieron, que mejor inviertas tiempo en migrar a un servidor de base de datos de una vez, es buena la idea que esta haciendo pero al final vas a trabajar triple, porque esas instrucciones que vas a migrar a SQL solo te servirán para VFP en tablas nativas, y cuando realmente quieras ir a un servidor de base de datos mucho de ese codigo SQL no te va a servir por el simple hecho que vas a usar funciones de VFP dentro de SQL que no sirven en un servidor de base de datos.

saludos

[JCReyna]

Gracias Antonio por tu comentario.

Cree una clase para manejar los datos (sqldatos) la cual tiene diferentes propiedades y métodos.

En la propiedad "base" se asigna la base de datos a manejar, en este caso VFP.

La clase tiene los metodos: Buscar, Insertar, Actualizar y Borrar.

Todos los metodos tienen:

if base = 'VFP'

   ...

   ...

else

   ...

   ...

endif

En los formularios creo una instancia de la clase, asigno las propiedades y ejecuto el metodo correspondiente.

En el comando a ejecutar no pongo ninguna instrucción de VFP.

Por ejemplo para checar si ya existe la factura 'A12' del proveedor '0001' :

wcvepro = alltrim(thisform.cvepro.value)

wnumfac = alltrim(thisform.numfac.value)

wsqlnumfac = padr(wnumfac,15,' ')

wsqlcmd = 'select * from tabla where tabla.num_fac = ?wsqlnumfac and tabla.cve_pro = ?wcvepro into cursor datos'

(El * es solo con fines ilustrativos, en realidad van los nombres de los campos a extraer.)

La idea es que cuando la base de datos ya nos sea VFP actualizar la clase (sqldatos) con lo necesario para que continue funcionando.

De entrada, sqlconnect, sqlexec y sqldisconnect.

Si resulta que para alguna base de datos las variables en lugar de empezar con '?' debe ser '@', creo que con :

strtran(wsqlcmd,'?','@') se solucionaria el problema.

Voy bien o me regreso.

Saludos

[Miguel Antúnez]

Estimado JCReyna,

Con esta forma de trabajo, no estamos aprovechando al máximo el potencial de la base de datos. Además, hay una brecha de seguridad importante al tener nuestras tablas expuestas a la capa de interfaz. Esta situación se podría mejorar significativamente mediante el uso de procedimientos almacenados.

Saludos cordiales,

--
Blog de la Comunidad Visual FoxPro en Español http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/1fed8c94-eb65-4baa-932a-9bb49d31c44dn%40googlegroups.com.

[Antonio Meza]

Entiendo lo que quieres hacer, sin embargo créeme que no te va a servir mucho ese codigo al final vas a tener que estudiar nuevamente y volver a rediseñar todo.

A demás no solo se trata de traer y enviar datos, está el manejo de conexión y sobre todo el manejo de Transacciones que es lo mas complicado, todo esto ya lo hace FoxyDb que igualmente ya te recomendaron.

Otro punto aun mas importante es el tema de tus datos, si estan normalizados para poder pasar de igual forma a un servidor de base de datos, porque ya no puedes traerte todos los registros solo para agregar uno nuevo, o consultar un registro del listado completo, etc.

Si no tienes normalizadas tus tablas definitivamente ve estudiando para migrar a un servidor de base de datos, porque si no lo haces, entonces ya no vas a trabajar triple si no cuádruple!!!!

En cuanto al uso de Store Procedure (SP) no soy muy fanboy de ellos, de hecho en el mundo web y movil es muy raro que usen SP, salvo para casos donde el proceso es mediano a grande entonces si aplican, pero para hacer simples consultas o inserciones es un desperdicio de tiempo en crearlos, administrarlos y ejecutarlos, un ejemplo sencillo una tabla detalle que tienes 100 registros, de los cuales solo modificas el registro 30 y solo su campo 3 de ese registro, tienes que regresar al servidor los 100 registros y se tienen que reemplazar si o si para solo cambiar un campo de un registro.

Para acceder a los datos normalmente se usa un ORM, que es el que esta por debajo de la API Rest.

saludos

[Miguel Antúnez]

Estimado Antonio.

Entiendo tu punto de vista sobre la preferencia de no utilizar procedimientos almacenados (Store Procedures o SP) para tareas simples. Sin embargo, creo que hay varios aspectos importantes que considerar en favor de su uso, especialmente en términos de seguridad, organización, escalabilidad y reutilización.

Seguridad y Control de Acceso: Los procedimientos almacenados permiten una capa adicional de seguridad al restringir el acceso directo a las tablas de la base de datos. Los usuarios pueden tener permisos para ejecutar procedimientos específicos sin tener acceso a la estructura subyacente de la base de datos, reduciendo el riesgo de operaciones maliciosas o accidentales.

Organización y Mantenimiento: Trabajar en capas y tener procedimientos almacenados bien definidos da un orden claro al sistema. Los cambios en la lógica de negocio se pueden hacer en un solo lugar (el SP), lo que facilita el mantenimiento y la evolución del sistema sin afectar otras partes del código.

Escalabilidad: Los procedimientos almacenados pueden ser optimizados por el motor de la base de datos, mejorando la eficiencia de las operaciones complejas y asegurando un mejor rendimiento a medida que el sistema crece. Las consultas complejas y operaciones masivas se benefician significativamente de esta optimización.

Reusabilidad: Al encapsular la lógica en procedimientos almacenados, se promueve la reutilización de código. Esto reduce la duplicación y la posibilidad de errores, ya que una lógica de negocio implementada correctamente en un SP puede ser utilizada en múltiples aplicaciones o partes del sistema sin necesidad de reescribir el código.

Aunque para operaciones muy simples, como una inserción o consulta individual, puede parecer una sobrecarga el uso de procedimientos almacenados, su valor se vuelve evidente cuando se considera el panorama completo del desarrollo y mantenimiento de sistemas escalables y seguros. La inversión en su creación y administración se justifica ampliamente por los beneficios a largo plazo en términos de seguridad, organización y eficiencia.

Saludos.

--
Blog de la Comunidad Visual FoxPro en Español http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/ed69d50b-ee0f-4fba-9662-dca6ad8dcfbdn%40googlegroups.com.

[Antonio Meza]

Creo que el gran problema y aun no lo vez es que en este grupo la mayoría aun usa Tablas DBF's y no se pasan a un servidor de base de datos por los X motivos que quieran poner,  pero el mas importante es el diseño de la base de datos, no migran por el miedo a rediseñar o reestructurar su base de datos y toda la logica, porque todos los que somos programadores de VFP cuando usamos tablas DBF's nos mal acostumbramos a la gran velocidad en las consultas y traernos todos los datos para solo mostrar un registro al usuario jajajajajajajaj

Entonces añádele que use Store Procedure, cuando ni siquiera saben usar SQL ???

Lamentablemente la mayoría de este grupo no somos DBA y contratar uno pues sale un ojo de la cara jajajaja.

Como recomendación para el compañero que inicio esta conversión es que primero estudie si sus tablas son candidatas a migrar a un servidor de base de datos y sino pues le va a tocar estudiar diseño de base de datos o contratar un DBA.

Nuevamente para procesos medianos y grandes los Store Procedure son lo mejor.

Nota: Cuando diseñe FoxyDb tanto aqui en el grupo pero mayormente por privado me solicitaban que FoxyDb pudiera trabajar con DBF's y mi respuesta siempre fue la misma "NO" porque era un forma de ayudarlos a ya olvidarse de los DBF's

Los servidores de bases de datos son el común denominador entre los lenguajes de programación, es decir al usar Mysql, SqlServer, MariaDb, PostGreSql, Oracle, etc, puedes utilizar cualquier lenguaje de programación, pero si usas DBF's la historia ya la saben.

saludos

[Carlos X. Montes]

Gracias a Dios no somos DBA, porque lo único normal en esos tipos son sus tablas.  (Es viernes)

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/7490355c-877e-47f7-a6fd-3cf9a2be282an%40googlegroups.com.

[Miguel Antúnez]

Es cierto que muchos de nosotros en el grupo aún utilizamos tablas DBF's debido a su velocidad y simplicidad. Sin embargo, es crucial reconocer que podemos y debemos dominar un sistema de gestión de bases de datos (SGBD) con la misma intensidad y dedicación con la que manejamos FoxPro. La migración a un SGBD no solo es posible, sino que es una evolución natural que nos permitirá aprovechar tecnologías más avanzadas y mejorar la eficiencia y escalabilidad de nuestros sistemas.

El miedo a rediseñar o reestructurar la base de datos es comprensible, pero es superable. El diseño de bases de datos puede parecer intimidante al principio, especialmente para aquellos que no se consideran DBA. Sin embargo, con la formación adecuada y el enfoque correcto, podemos adquirir las habilidades necesarias para llevar a cabo esta transición. Aquí es donde entra en juego el potencial del SGBD mediante el uso de Stored Procedures, funciones, triggers, vistas, y funciones tipo tabla, que pueden optimizar y agilizar los procesos de base de datos para cualquier envergadura.

Para aquellos que aún están indecisos, recomiendo empezar por evaluar si sus tablas actuales son candidatas para migrar a un servidor de base de datos. Si no es así, será necesario estudiar diseño de bases de datos, reestructurar y empezar bien.

Invito a todos a ver esta transición como una oportunidad de crecimiento y aprendizaje. Dominar un SGBD no solo es alcanzable, sino que también nos posicionará mejor en un entorno tecnológico en constante evolución.

Saludos.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/7490355c-877e-47f7-a6fd-3cf9a2be282an%40googlegroups.com.

[Antonio Meza]

Les recomiendo el siguiente video sobre los Store Procedure si realmente les interesa el tema porque es entre 2 personas contrarias, es decir una que usa los SP y la otra que no los usa y dan buenos argumentos ambos

En mi caso coincido con el que no los usa jajajajajajaja PERO como dije para procesos medianos o grandes por cuestiones de rendimiento definitivamente si, y de hecho se toca ese tema en el video, porque no es lo mismo traerte 1 millon de registros para realizar un calculo en el cliente, que mandar parámetros en un SP y todo se procese en el servidor y obtengas el resultado.

https://www.youtube.com/watch?v=BcW7O2Yj7G4

saludos

[Miguel Antúnez]

¡Gracias por compartir el video! Es muy interesante escuchar puntos de vista contrarios sobre el uso de los Stored Procedures (SP). Es esencial considerar diferentes perspectivas para tomar decisiones informadas.

Sin embargo, quiero reafirmar mi postura sobre la importancia y utilidad de los SP, especialmente en los puntos 2,4 y 6.

Agradezco nuevamente el aporte del video, pero reafirmo mi convicción de que los Stored Procedures son una herramienta poderosa y esencial para optimizar el rendimiento y la eficiencia en la gestión de bases de datos, en todos los contextos, especialmente en contextos de mediana y gran escala.

Saludos.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/fd12e3bc-5441-425d-add8-11de44449f95n%40googlegroups.com.

[Esteban Herrero]

Un Consejo p los nuevos en SQL o q hasta el día de hoy usan DBF y no saben como pasar a un motor de SQL es empezar con este instructivo q hizo hace unos años Walter sobre VFP + Firebird.

http://www.mediafire.com/file/nb74e3oaf9g9l4j/Visual_FoxPro_y_Firebird_SQL.PDF

Acá van a ver de 0 como empezar con un motor SQL, yo empecé de esta manera y luego podrás elegir seguir con Firebird o pasar a cualquier otro motor, pero bueno acá vas a poder ver desde instalar el motor hasta la definición de las tablas y sus índices, y manejo de Triggers, Generadores, SP y demás.

Yo cuando leo q quieren pasar sus dbf a motores, podrás pasar las tablas mas comunes (artículos, tablas varias), pero las tablas maestras, tenés q redifinirlas, normalizarlas, no sirve pasar de DBF tal cual a una tabla de SQL.

En fin, mi granito de arena, hace 7/8 años q empecé x acá y nunca mas DBFs.

Saludos

Esteban

[Miguel Antúnez]

Feliz fin de semana. y vivir con emoción una migración de DBF a un SGBD

 Emociones DB (2).pdf

--

Blog de la Comunidad Visual FoxPro en Español http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/fd0825b8-2dee-440f-b6fe-b90d956babae%40yahoo.com.ar.