FoxyDb ¿Como visualizar los Cambios en el Cursor Local antes de realizar el Update hacia el motor de Bd?

[Ricardo Soldini]

Como estan

Tengo el siguiente Codigo en un metodo

   Update articulos_bodega Set stock = stock - Thisform.cantidad_vta Where id_articulo_bodega = Thisform.id_articulo_bodega

       IF articulos_bodega.stock <= 1 &&si estaba en uno asumo que qudara en 0 por lo que cambi estado

          UPDATE articulos_tot SET id_tab_estados = thisform.id_vendido WHERE id_articulos = thisform.id_articulos 

       endif

Sin embargo al hacer un debug y monitorear el contenido de 

'articulos_bodega.stock'  no se visualiza ningun cambio despues del Update

No Obstante cuando 

ejecuto el comando

if odb.changes('articulos_bodega') 

    odb.update('articulos_bodega',id_articulos_bodega,.t.) 

endif   

y voy por el Administrador de Bases de Datos y ejecuto una consulta directa veo que si realizo la rebaja

pero desde el form no lo veo 

¿hay alguna manera de ver reflejado en el cursor el cambio'

Gracias

[Antonio Meza]

No he usado Update para aplicar cambios a un cursor siempre uso Replace, pero si quieres ver los cambios puedes hacer un select al cursor con buffering

Select * from articulos_bodega WITH (BUFFERING = .T.) INTO CURSOR temp_Revisar

Te va a crear un cursor con los cambios que tenga, ya que si haces el mismo select sin el  WITH (BUFFERING = .T.) te muestra el cursor sin cambios aun cuando este los contenga.

Incluso después del Update si muestras en un wait windows o messagebox el valor del campo modificado con Update no te muestra el cambio? no se si el Debug no muestra los cambios cuando hay buffering de por medio.

saludos

Antonio Meza

[Gabriel Araya Garcia]

Y porque no utilizas un flag que sea parte de los cambios, es decir que esté incluido en el UPDATE, y lo muestras en alguna parte de tu ventana?

Antes del UPDATE lo podrias poner en false y despues del UPDATE lo pones en true.

Esa sería una forma de comprobar si el cambio se llevó a efecto, y posibilitará también trazarlo con el debug.

Al menos eso era una de las formas que utilizaba cuando programaba en VFP9

Otra cosa, el update esta totalmente obsoleto, además funciona solo en la seudo BD nativa de VFP, para las bases de datos verdaderas (ORACLE, SQL Server, Mongo,..etc.) el update no funciona.

Saludos.  

Gabriel Araya Garcia

GMI - Desarrollo de Sistemas Informáticos

--
Visita el 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/830d2d61-3dd8-4b3f-9e55-f2e6e561a912n%40googlegroups.com.

[Ricardo Soldini]

Otra cosa, el update esta totalmente obsoleto, además funciona solo en la seudo BD nativa de VFP, para las bases de datos verdaderas (ORACLE, SQL Server, Mongo,..etc.) el update no funciona.

No entiendo eso ¿como Obsoleto? Adjunto Informacion de Microsoft respecto de la trilogia Udpdate insert Delete

UPDATE, DELETE, and INSERT Statements - SQL Server | Microsoft Docs

UPDATE, DELETE, and INSERT Statements

• 
  

SQL-based applications make changes to tables by executing the UPDATE, DELETE, and INSERT statements. These statements are part of the Minimum SQL grammar conformance level and must be supported by all drivers and data sources.

The syntax of these statements is:

UPDATE table-name

SET column-identifier = {expression | NULL}

[, column-identifier = {expression | NULL}]...

[WHERE search-condition]

DELETE FROM table-name[WHERE search-condition]

INSERT INTO table-name[( column-identifier [, column-identifier]...)]

Con respecto al problema que reporte lo resolvi asignando a la variable (old_stock ) el stock  que tengo antes de rebajar 

old_Stock=articulos_bodega.stock

old_Stock = old_stock - thisform.cantidad_vta

   Update articulos_bodega Set stock = old_stock  Where id_articulo_bodega = Thisform.id_articulo_bodega

       IF old_stock = 0  &&si queda en 0 cambio estado de articulo 

          UPDATE articulos_tot SET id_tab_estados = thisform.id_vendido WHERE id_articulos = thisform.id_articulos 

       endif

[Gabriel Araya Garcia]

He cometido un error !!,. quise decir el REPLACE

Gabriel Araya Garcia

GMI - Desarrollo de Sistemas Informáticos

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/2f7df761-53c5-4c1a-9686-54232aae9c1en%40googlegroups.com.

[Ivan Martinez]

Que sustituye al update ?

Y porque ya no se usa ?

Ivan Martinez von Halle

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAKVvSDD%2BK5TkuHmY7mjf3SC4YSMxETfZR3o42EPZjPvjhvCDPg%40mail.gmail.com.

[Ricardo Soldini]

No ivan , se equivoco y quiso poner Replace. Cosa que es cierto es mejor usar Update que es comuna a todos los Motores de BD

[Carlos Miguel FARIAS]

El append blank y los replace posteriores son extremadamente "malos". Eso ya se determinó con las primeras versiones de Fox que permitían el INSERT de SQL (el otro INSERT, que era físico, era lo peor de lo peor).

El por qué es malo la combinación append blank y replace, porque hace todo al menos dos veces.

Cuando se hace el append blank, se agrega un registro con todos sus campos en "blanco", ceros, nulos, vacíos, según el tipo de campo. Eso impacta además en crear las respectivas entradas en todos los índices que tenga definida la tabla.

En un entorno multiusuario, puede darse que dos usuarios intenten agregar un registro a la vez, el 1º append lo agrega y deja la clave primaria y demás (salvo autoincremental) con una clave en blanco, que debe registrarse en el índice, eso puede implicar expansión del índice (arbol B+) por haberse llenado un nodo (lo mismo pasa con todos los otros índices, donde se agregan las respectivas entradas (salvo nulos, si la clave lo soporta). El 2º que intenta agregar el registro, obtendrá un error de clave duplicada por la PK, y por todas las claves candidatas. El 2º usuario se ve frustrado porque el sistema da error y él no ingresó datos.

Luego, cada replace, va cambiando los datos del registro recién agregado (para el 1º usuario, mientras el otro maldice), eso produce nuevamente, el agregado de nuevas entradas en cada uno de los índices (segundo impacto en los árboles B+) y un tercer impacto, al eliminar las claves que correspondían a los campos en blanco que ahora se rellenan.

Si además se utiliza integridad referencial provista por VFP, tienes otra serie de fuentes de errores, por solapamiento de inserciones (o agregados).

En cambio, usando un INSERT de SQL, todo se hace de una vez, (los índices se modifican una vez, no dos veces) no hay errores por el momentáneo registro en blanco. Si aparece una clave duplicada, es por duplicación "real" de datos, no por la forma de trabajar el VFP.

El concepto de APPEND BLANK y REPLACE, viene de la época del VULCAN y el dBase II, EVOLUCIONEMOS.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/a694aef5-a5a3-4e5d-9f4d-8ca1f83d9875n%40googlegroups.com.

[Antonio Meza]

Es correcto lo que mencionas!!! PERO!!!!! jajajajaj

En mi caso no uso tablas DBF y no uso índices, lo que uso son CURSORES y sin índices, que son devueltos por SQLEXEC por medio de FoxyDB desde un servidor MariaDB, y esos cursores son por Usuario, es decir no se comparten!!!

Estoy totalmente de acuerdo que es mejor usar sentencias SQL en tablas DBF incluso en Cursores, sin embargo en lo personal se me hace mas fácil usar REPLACE que UPDATE, si uso INSERT INTO y no uso APPEND BLANK.

saludos

Antonio Meza