Xailer & OZ Software

Vamos a ver. Yo estoy utilizando dbf temporal mia propia sin utilizar
datasets. Pero se me presento una cuestion que seria tambien interesante
conocer su funcionamiento con datasets, o al menos saber como lo soluciona.
Me explico : Un ejemplo : Una dbf llamada "tablamadre" la cual tiene 5
registros, "A", "B", "C", "D", "E" respectivamente. 2 puestos en red
atacando la misma dbf pero con datasets por odbc con lo cual ataca a una dbf
temporal. Bien hasta aqui tenemos PC Nº 1 en el mismo apartado que PC Nº 2.
Supongamos que el PC Nº 2 Cambia "A" por "J", y ahora supongamos que el PC
Nº 1 decide eliminar "A", y sale antes el PC Nº 1 con lo cual actualiza la
"tablamadre" antes que el PC Nº 2. Ahora cuando abandone el apartado el PC
Nº 2 no encontrara "A" en la "tablamadre" para proceder a actualizar su
valor. Como soluciona este problema xailer con los datasets?
Atentamente : Francisco Sanchez GERENTE GRUPO ST - Software TOTAL -

Francisco,
>> Supongamos que el PC Nº 2 Cambia "A" por "J"
ok
>>supongamos que el PC Nº 1 decide eliminar "A"
Recibe un error diciendo que el registro ya no existe y se aborta la
operación. Esto es lo que se llama bloqueo optimista. Antes de actualizar
ninguna fila se comprueba que la fila no ha cambiado desde que se recupero.
Con que haya cambiado un sólo campo el proceso se para, y logicamente si ni
existe con mucha más razón.
Las DBF temporales sólo se usan para acceder a ODBC, y por más que intento
explicar que son tan sólo un buffer y que no existe ninguna diferencia sobre
si hubiesemos usado una matriz veo que no se tiene claro.
En motores SQL no existe la idea de 'y si el PC 1 se sale antes del PC 2...'
Eso es historía. En SQL no existen punteros de navegación, ni recnos y
precisamente por eso; porque uno no se puede fiar de ellos. Para que me
entiendas, desde un Seek() a un Delete() puede haber tan sólo milisegundos,
pero suficientes para un puesto borre el registro antes que tu. En SQL nunca
hay este problema, porque no hay punteros de navigación, cual operción
requiere una cláusula WHERE que indique el las filas que va a afectar y
siempre se recalculan en cada operación, por lo tanto, incluso anque Xailer
no tuviese bloqueo optimista tu operación no fallaría ya que el borrado que
hace el PC 1 NUNCA se llegará a producir pues "A" ya no existe.
Un saludo,
"Francisco Sanchez" <francisco@softwaretotal.biz> escribió en el mensaje
news:[email=423dadd8@ozsrv2.ozlan.local...]423dadd8@ozsrv2.ozlan.local...[/email]
> Vamos a ver. Yo estoy utilizando dbf temporal mia propia sin utilizar
> datasets. Pero se me presento una cuestion que seria tambien interesante
> conocer su funcionamiento con datasets, o al menos saber como lo
> soluciona.
> Me explico : Un ejemplo : Una dbf llamada "tablamadre" la cual tiene 5
> registros, "A", "B", "C", "D", "E" respectivamente. 2 puestos en red
> atacando la misma dbf pero con datasets por odbc con lo cual ataca a una
> dbf temporal. Bien hasta aqui tenemos PC Nº 1 en el mismo apartado que PC
> Nº 2. Supongamos que el PC Nº 2 Cambia "A" por "J", y ahora supongamos que
> el PC Nº 1 decide eliminar "A", y sale antes el PC Nº 1 con lo cual
> actualiza la "tablamadre" antes que el PC Nº 2. Ahora cuando abandone el
> apartado el PC Nº 2 no encontrara "A" en la "tablamadre" para proceder a
> actualizar su valor. Como soluciona este problema xailer con los datasets?
>
> Atentamente : Francisco Sanchez GERENTE GRUPO ST - Software TOTAL -
>

ok
"Ignacio Ortiz" <NoNameToAvoidSpam@ozs.com> escribió en el mensaje
news:[email=423df6b1@ozsrv2.ozlan.local...]423df6b1@ozsrv2.ozlan.local...[/email]
> Francisco,
>
>>> Supongamos que el PC Nº 2 Cambia "A" por "J"
> ok
>
>>>supongamos que el PC Nº 1 decide eliminar "A"
> Recibe un error diciendo que el registro ya no existe y se aborta la
> operación. Esto es lo que se llama bloqueo optimista. Antes de actualizar
> ninguna fila se comprueba que la fila no ha cambiado desde que se
> recupero. Con que haya cambiado un sólo campo el proceso se para, y
> logicamente si ni existe con mucha más razón.
>
> Las DBF temporales sólo se usan para acceder a ODBC, y por más que intento
> explicar que son tan sólo un buffer y que no existe ninguna diferencia
> sobre si hubiesemos usado una matriz veo que no se tiene claro.
>
> En motores SQL no existe la idea de 'y si el PC 1 se sale antes del PC
> 2...' Eso es historía. En SQL no existen punteros de navegación, ni
> recnos y precisamente por eso; porque uno no se puede fiar de ellos. Para
> que me entiendas, desde un Seek() a un Delete() puede haber tan sólo
> milisegundos, pero suficientes para un puesto borre el registro antes que
> tu. En SQL nunca hay este problema, porque no hay punteros de navigación,
> cual operción requiere una cláusula WHERE que indique el las filas que va
> a afectar y siempre se recalculan en cada operación, por lo tanto, incluso
> anque Xailer no tuviese bloqueo optimista tu operación no fallaría ya que
> el borrado que hace el PC 1 NUNCA se llegará a producir pues "A" ya no
> existe.
>
> Un saludo,
>
> "Francisco Sanchez" <francisco@softwaretotal.biz> escribió en el mensaje
> news:[email=423dadd8@ozsrv2.ozlan.local...]423dadd8@ozsrv2.ozlan.local...[/email]
>> Vamos a ver. Yo estoy utilizando dbf temporal mia propia sin utilizar
>> datasets. Pero se me presento una cuestion que seria tambien interesante
>> conocer su funcionamiento con datasets, o al menos saber como lo
>> soluciona.
>> Me explico : Un ejemplo : Una dbf llamada "tablamadre" la cual tiene 5
>> registros, "A", "B", "C", "D", "E" respectivamente. 2 puestos en red
>> atacando la misma dbf pero con datasets por odbc con lo cual ataca a una
>> dbf temporal. Bien hasta aqui tenemos PC Nº 1 en el mismo apartado que PC
>> Nº 2. Supongamos que el PC Nº 2 Cambia "A" por "J", y ahora supongamos
>> que el PC Nº 1 decide eliminar "A", y sale antes el PC Nº 1 con lo cual
>> actualiza la "tablamadre" antes que el PC Nº 2. Ahora cuando abandone el
>> apartado el PC Nº 2 no encontrara "A" en la "tablamadre" para proceder a
>> actualizar su valor. Como soluciona este problema xailer con los
>> datasets?
>>
>> Atentamente : Francisco Sanchez GERENTE GRUPO ST - Software TOTAL -
>>
>
>