Xailer & OZ Software

Hola,
Alguien ha probado los í­ndices Unique de ads con Xailer?
En teorí­a, cuando tenemos activo un í­ndice de tipo unique, si intentamos
introducir una clave que ya existe en el í­ndice, tiene que generar un
error, pero no he consequido hacerlos funcionar.
Si meto una clave duplicada, en lugar de un error me "borra" el
contenido del browse, que no vuelve a aparecer hasta que reabro la
tabla.
En el caso de que funcione. ¿Qué tipo de error da? ¿La puedo cazar para
avisar al usuario de que el código está repetido o me da un error y se
sale del programa?
Un saludico,
Fredy

Fredy,
nunca he usado estos índices con ADS, pero sí llegué a usarlos hace mucho
tiempo con NTX y con CDX en Clipper. Y según mi experiencia, nunca deberían
haberse llamado UNIQUE porque hace pensar en lo que no son. Te cuento:
Lo que hacen estos índices es que sólo exista una entrada en el índice por
cada clave única. Es decir, si hay tres registros con la clave "000000",
entonces sólo uno de ellos aparece en el índice. Pero los 3 están en el dbf.
Esto tiene la consecuencia de que cuando recorres el fichero con un WHILE
!EOF() / SKIP / ENDDO sólo ves una parte de los registros que hay en la
tabla, y te saltas los duplicados.
Aún así, esta forma de funcionar podría ser útil en algunos casos, salvo por
otro problema que yo me tropecé (y que fue la razón por la que nunca más
volví a usarlos): supón el caso anterior, donde hay 3 registros con una
misma clave pero sólo uno de ellos aparece en el índice. Si eliminas ese
registro, lo lógico sería que uno de los 2 que quedan ocupara esa entrada en
el índice... pero me temo que no, simplemente desaparece y ya no vuelves a
encontrar de nuevo ningún registro con esa clave hasta que regeneres el
índice
El hecho de que te borre en browse cuando metes un registro "duplicado" de
debe casi seguramente a este comportamiento. Al añadir ese registro, no
aparece en el índice, y al hacer un skip o skip(-1), el puntero salta a
eof(), y el browse "cree" que no hay registros que mostrar.
--
Un saludo,
José F. Giménez

Hola!
Sí­, lo que dices es correcto para las dbf, pero con las tablas .adt de
advantage la cosa cambia, y mucho. Con las .adt sí­ que son í­ndices de
clave única, ya que lo que hacen es no permitirte introducir un dato si
el í­ndice coincide con otro ya existente. Como ves, la diferencia es
brutal, ya que este tipo de í­ndices unique sí­ son muy interesantes. Las
malas noticias son que no me funcionan en Xailer.
Nos vemos en Murcia el 18.
Un saludico,
Fredy
-----------------------------------
Os dejo lo que pone la documentación de advantage, ya que esta
caracterí­stica de los í­ndices en ads no es muy conocida
Unique Indexes
The unique property of index orders is very different depending on the
Advantage table type being used. For information on unique indexes, see
ADI Unique Indexes or Xbase Unique Indexes.
Xbase Unique Indexes.
----------------------
An Xbase index order created with the "unique" property will only
include records that are referenced by unique values. If two records
result in the identical key value, then only one of the records will be
referenced by the index. The second is simply never added to the index,
and no error is reported. If the record (of the two with identical key
values) referenced by the unique index is modified such that the key
value changes, that index key will be removed from the index, but the
other record with the identical key value will NOT be added to the
unique index. Therefore, no key will be referencing the unique record in
the index. Unique Xbase index orders do not guarantee uniqueness of the
field(s) in the index order's key expression. This is the traditional
Xbase behavior of the "unique" property in Xbase indexes.
ADI Unique Indexes
------------------
An ADI index order created with the "unique" property enforces all
records in the table to be referenced via a unique key. When creating
the index order, if a record is found that would cause a non-unique key
to be placed in the index, an error will be generated and the index
order will not be created. If a unique index is successfully created,
and a new record is inserted or updated in which the key produced from
the record is not unique, an error will be returned and the record
update will not be allowed. At that point, the record must be modified
such that the key produced is unique. If the record change is not
desired or possible, either the update must be canceled or the table and
index must be closed.

Fredy,
Cambia 'Xailer' por 'Xharbour' pues obviamente Xailer no hace nada con los
RDDs.
Saludos,
"Fredy" <fredy@airtel.net> escribió en el mensaje
news:[email=MPG.1d13b206eac2b072989711@news.ozs.com...]MPG.1d13b206eac2b072989711@news.ozs.com...[/email]
Hola!
Sí, lo que dices es correcto para las dbf, pero con las tablas .adt de
advantage la cosa cambia, y mucho. Con las .adt sí que son índices de
clave única, ya que lo que hacen es no permitirte introducir un dato si
el índice coincide con otro ya existente. Como ves, la diferencia es
brutal, ya que este tipo de índices unique sí son muy interesantes. Las
malas noticias son que no me funcionan en Xailer.
Nos vemos en Murcia el 18.
Un saludico,
Fredy
-----------------------------------
Os dejo lo que pone la documentación de advantage, ya que esta
característica de los índices en ads no es muy conocida
Unique Indexes
The unique property of index orders is very different depending on the
Advantage table type being used. For information on unique indexes, see
ADI Unique Indexes or Xbase Unique Indexes.
Xbase Unique Indexes.
----------------------
An Xbase index order created with the "unique" property will only
include records that are referenced by unique values. If two records
result in the identical key value, then only one of the records will be
referenced by the index. The second is simply never added to the index,
and no error is reported. If the record (of the two with identical key
values) referenced by the unique index is modified such that the key
value changes, that index key will be removed from the index, but the
other record with the identical key value will NOT be added to the
unique index. Therefore, no key will be referencing the unique record in
the index. Unique Xbase index orders do not guarantee uniqueness of the
field(s) in the index order's key expression. This is the traditional
Xbase behavior of the "unique" property in Xbase indexes.
ADI Unique Indexes
------------------
An ADI index order created with the "unique" property enforces all
records in the table to be referenced via a unique key. When creating
the index order, if a record is found that would cause a non-unique key
to be placed in the index, an error will be generated and the index
order will not be created. If a unique index is successfully created,
and a new record is inserted or updated in which the key produced from
the record is not unique, an error will be returned and the record
update will not be allowed. At that point, the record must be modified
such that the key produced is unique. If the record change is not
desired or possible, either the update must be canceled or the table and
index must be closed.

Fredy,
Intenta hacer un pequeño ejemplo en modo consola. Si consigues que falle
publicala en el foro de xharbour.org seguro que lo resolverán rápido.
Un saludo,
"Ignacio Ortiz de Zúñiga" <InvalidAccount@ozs.com> escribió en el mensaje
news:42a9a038$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> Fredy,
>
> Cambia 'Xailer' por 'Xharbour' pues obviamente Xailer no hace nada con los
> RDDs.
>
> Saludos,
>
> "Fredy" <fredy@airtel.net> escribió en el mensaje
> news:[email=MPG.1d13b206eac2b072989711@news.ozs.com...]MPG.1d13b206eac2b072989711@news.ozs.com...[/email]
> Hola!
>
> Sí, lo que dices es correcto para las dbf, pero con las tablas .adt de
> advantage la cosa cambia, y mucho. Con las .adt sí que son índices de
> clave única, ya que lo que hacen es no permitirte introducir un dato si
> el índice coincide con otro ya existente. Como ves, la diferencia es
> brutal, ya que este tipo de índices unique sí son muy interesantes. Las
> malas noticias son que no me funcionan en Xailer.
>
> Nos vemos en Murcia el 18.
> Un saludico,
> Fredy
>
>
> -----------------------------------
> Os dejo lo que pone la documentación de advantage, ya que esta
> característica de los índices en ads no es muy conocida
>
> Unique Indexes
>
> The unique property of index orders is very different depending on the
> Advantage table type being used. For information on unique indexes, see
> ADI Unique Indexes or Xbase Unique Indexes.
>
>
> Xbase Unique Indexes.
> ----------------------
> An Xbase index order created with the "unique" property will only
> include records that are referenced by unique values. If two records
> result in the identical key value, then only one of the records will be
> referenced by the index. The second is simply never added to the index,
> and no error is reported. If the record (of the two with identical key
> values) referenced by the unique index is modified such that the key
> value changes, that index key will be removed from the index, but the
> other record with the identical key value will NOT be added to the
> unique index. Therefore, no key will be referencing the unique record in
> the index. Unique Xbase index orders do not guarantee uniqueness of the
> field(s) in the index order's key expression. This is the traditional
> Xbase behavior of the "unique" property in Xbase indexes.
>
> ADI Unique Indexes
> ------------------
> An ADI index order created with the "unique" property enforces all
> records in the table to be referenced via a unique key. When creating
> the index order, if a record is found that would cause a non-unique key
> to be placed in the index, an error will be generated and the index
> order will not be created. If a unique index is successfully created,
> and a new record is inserted or updated in which the key produced from
> the record is not unique, an error will be returned and the record
> update will not be allowed. At that point, the record must be modified
> such that the key produced is unique. If the record change is not
> desired or possible, either the update must be canceled or the table and
> index must be closed.
>

Hola!
He seguido dándole vueltas al tema de los í­ndices únicos, y parece que
es algún error mí­o, ya que ahora casi me funcionan.
El problema es que realmente funcionan, pero de forma tan automática que
por programa no me entero de nada.
La tabla que utilizo tiene entre otros, los campos
nCodigo: es de tipo AutoInc y no está indexado
Explotacion: tipo carácter 10, está indexado como unique.
tengo ya los datos
nCodigo Explotacion
--------- ------------
1 345-HU-456
2 224-HU-200
Si inserto un registro con Explotación=224-hu-200, como ya existe esa
clave no me lo inserta, pero no me dice nada. Si después inserto el 100-
Z-100, la tabla se queda
nCodigo Explotacion
--------- ------------
1 345-HU-456
2 224-HU-200
4 100-Z-100
Como se ve, ha saltado el incremental con el registro duplicado y no lo
tengo en la tabla. Perfecto.
El problema: Que el usuario a insertado un dato que ya existí­a, y por lo
tanto realmente no lo ha insertado, pero yo no le puedo avisar desde
programa.
En el datasource tengo lDisplayErrors a .t., al igual que en el dataset.
Si hago un logdebug( ::odbf:update()) me devuelve .t.
Yo creo que lo correcto serí­a que update devolviera .f., ya que el
registro realmente no se ha insertado ¿no?
Voy a ver si puedo separar ese módulo de la aplicación y os mando el
ejemplo.
Un saludico,
Fredy
In article <42a9a258$1@ozsrvnegro.ozlan.local>, InvalidAccount@ozs.com
says...
> Fredy,
>
> Intenta hacer un pequeño ejemplo en modo consola. Si consigues que falle
> publicala en el foro de xharbour.org seguro que lo resolverán rápido.
>
> Un saludo,
>
> "Ignacio Ortiz de Zúñiga" <InvalidAccount@ozs.com> escribió en el mensaje
> news:42a9a038$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> > Fredy,
> >
> > Cambia 'Xailer' por 'Xharbour' pues obviamente Xailer no hace nada con los
> > RDDs.
> >
> > Saludos,
> >
> > "Fredy" <fredy@airtel.net> escribió en el mensaje
> > news:[email=MPG.1d13b206eac2b072989711@news.ozs.com...]MPG.1d13b206eac2b072989711@news.ozs.com...[/email]
> > Hola!
> >
> > Sí­, lo que dices es correcto para las dbf, pero con las tablas .adt de
> > advantage la cosa cambia, y mucho. Con las .adt sí­ que son í­ndices de
> > clave única, ya que lo que hacen es no permitirte introducir un dato si
> > el í­ndice coincide con otro ya existente. Como ves, la diferencia es
> > brutal, ya que este tipo de í­ndices unique sí­ son muy interesantes. Las
> > malas noticias son que no me funcionan en Xailer.
> >
> > Nos vemos en Murcia el 18.
> > Un saludico,
> > Fredy
> >
> >
> > -----------------------------------
> > Os dejo lo que pone la documentación de advantage, ya que esta
> > caracterí­stica de los í­ndices en ads no es muy conocida
> >
> > Unique Indexes
> >
> > The unique property of index orders is very different depending on the
> > Advantage table type being used. For information on unique indexes, see
> > ADI Unique Indexes or Xbase Unique Indexes.
> >
> >
> > Xbase Unique Indexes.
> > ----------------------
> > An Xbase index order created with the "unique" property will only
> > include records that are referenced by unique values. If two records
> > result in the identical key value, then only one of the records will be
> > referenced by the index. The second is simply never added to the index,
> > and no error is reported. If the record (of the two with identical key

Fredy,
Yo creo que lo correcto, sin dudarlo, es que Harbour generase un run-time
error de la misma forma que se genera cuando no se hace un Reclock al grabar
un campo. (¿recuerdas? 'Lock required')
Sigo pensando que si se lo posteas en el foro de xharbour.org te lo
arreglaran de inmediato.
Un saludo,
"Fredy" <fredy@airtel.net> escribió en el mensaje
news:[email=MPG.1d1a44bbb3516503989712@news.ozs.com...]MPG.1d1a44bbb3516503989712@news.ozs.com...[/email]
Hola!
He seguido dándole vueltas al tema de los índices únicos, y parece que
es algún error mío, ya que ahora casi me funcionan.
El problema es que realmente funcionan, pero de forma tan automática que
por programa no me entero de nada.
La tabla que utilizo tiene entre otros, los campos
nCodigo: es de tipo AutoInc y no está indexado
Explotacion: tipo carácter 10, está indexado como unique.
tengo ya los datos
nCodigo Explotacion
--------- ------------
1 345-HU-456
2 224-HU-200
Si inserto un registro con Explotación=224-hu-200, como ya existe esa
clave no me lo inserta, pero no me dice nada. Si después inserto el 100-
Z-100, la tabla se queda
nCodigo Explotacion
--------- ------------
1 345-HU-456
2 224-HU-200
4 100-Z-100
Como se ve, ha saltado el incremental con el registro duplicado y no lo
tengo en la tabla. Perfecto.
El problema: Que el usuario a insertado un dato que ya existía, y por lo
tanto realmente no lo ha insertado, pero yo no le puedo avisar desde
programa.
En el datasource tengo lDisplayErrors a .t., al igual que en el dataset.
Si hago un logdebug( ::odbf:update()) me devuelve .t.
Yo creo que lo correcto sería que update devolviera .f., ya que el
registro realmente no se ha insertado ¿no?
Voy a ver si puedo separar ese módulo de la aplicación y os mando el
ejemplo.
Un saludico,
Fredy
In article <42a9a258$1@ozsrvnegro.ozlan.local>, InvalidAccount@ozs.com
says...
> Fredy,
>
> Intenta hacer un pequeño ejemplo en modo consola. Si consigues que falle
> publicala en el foro de xharbour.org seguro que lo resolverán rápido.
>
> Un saludo,
>
> "Ignacio Ortiz de Zúñiga" <InvalidAccount@ozs.com> escribió en el mensaje
> news:42a9a038$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> > Fredy,
> >
> > Cambia 'Xailer' por 'Xharbour' pues obviamente Xailer no hace nada con
> > los
> > RDDs.
> >
> > Saludos,
> >
> > "Fredy" <fredy@airtel.net> escribió en el mensaje
> > news:[email=MPG.1d13b206eac2b072989711@news.ozs.com...]MPG.1d13b206eac2b072989711@news.ozs.com...[/email]
> > Hola!
> >
> > Sí, lo que dices es correcto para las dbf, pero con las tablas .adt de
> > advantage la cosa cambia, y mucho. Con las .adt sí que son índices de
> > clave única, ya que lo que hacen es no permitirte introducir un dato si
> > el índice coincide con otro ya existente. Como ves, la diferencia es
> > brutal, ya que este tipo de índices unique sí son muy interesantes. Las
> > malas noticias son que no me funcionan en Xailer.
> >
> > Nos vemos en Murcia el 18.
> > Un saludico,
> > Fredy
> >
> >
> > -----------------------------------
> > Os dejo lo que pone la documentación de advantage, ya que esta
> > característica de los índices en ads no es muy conocida
> >
> > Unique Indexes
> >
> > The unique property of index orders is very different depending on the
> > Advantage table type being used. For information on unique indexes, see
> > ADI Unique Indexes or Xbase Unique Indexes.
> >
> >
> > Xbase Unique Indexes.
> > ----------------------
> > An Xbase index order created with the "unique" property will only
> > include records that are referenced by unique values. If two records
> > result in the identical key value, then only one of the records will be
> > referenced by the index. The second is simply never added to the index,
> > and no error is reported. If the record (of the two with identical key

Hola,
No, yo no lo veo así­.
Creo que la gracia de este tipo de í­ndices está en que el datacontrol se
encague de toda la gestión de registros duplicados en lugar de ser el
programador el que está mirando siempre si el dato que se introduce ya
existe.
Si me genera un runtime error no me sirve. Es que realmente no es un
error, es simplemente que ese dato ya existe. Se informa al usuario, se
le piden los datos de nuevo y listo.
Si cada vez que me introducen un código repetido se genera un error y
les saco del programa, me parece una forma un poco drástica de decir:
"dato repetido, inténtelo de nuevo".
Un saludico,
Fredy
--

Attached files ejemplo.zip (9.8 KB)Â

Por cierto,
En el ejemplo que os mando, se ve algo que me sucede muy a menudo.
Fijaros como el oTabCrtl1 está repetido en el inspector de objetos.
De vez en cuando, se me duplican algunos controles y para quitarlos
tengo que editar el .xfm a mano y eliminarlos.
Un saludico,
Fredy

Fredy,
Xailer ES BASICAMENTE una librería de xHarbour, y el soporte de ADS esta a
nivel de xHarbour, no a nivel de Xailer, por lo tanto es xHarbour el que
primeramente debe solucionarlo si es que hay algo que no funcione.
Todos los motores SQL arrojan un error y provocan un error de ejecución
cuando se intenta violar una restricción. Y esto ocurre en TODOS los
entornos de programación que yo conozco, siendo responsabilidad del
programador poner el típico TRY..CATCH para manejarlo.
La gracia de este tipo de índices es conseguir con certeza absoluta claves
primarias en las tablas, cosa que las DBFs no tienen, y no ahorrar trabajo
al desarrollador, pero eso es tan sólo mi opinión.
Un saludo,
"Fredy" <fredy@airtel.net> escribió en el mensaje
news:[email=MPG.1d1a6a875b879f9a989713@news.ozs.com...]MPG.1d1a6a875b879f9a989713@news.ozs.com...[/email]
Hola,
No, yo no lo veo así.
Creo que la gracia de este tipo de índices está en que el datacontrol se
encague de toda la gestión de registros duplicados en lugar de ser el
programador el que está mirando siempre si el dato que se introduce ya
existe.
Si me genera un runtime error no me sirve. Es que realmente no es un
error, es simplemente que ese dato ya existe. Se informa al usuario, se
le piden los datos de nuevo y listo.
Si cada vez que me introducen un código repetido se genera un error y
les saco del programa, me parece una forma un poco drástica de decir:
"dato repetido, inténtelo de nuevo".
Un saludico,
Fredy