ODBC y borrado de datos

[fredy[1]]

Hola,
Estoy mirando el tema de borrar datos de una tabla que está en una BD
Firebird y me surgen algunas preguntas.
1.- He visto que tanto el DataSource como el DataSet tienen la propiedad
lDisplayErrors, que nos indica si queremos mostrar los errores tal y
como los genera la base de datos, sin embargo, sólo me funciona
modificando la del Datasource. En el Dataset, ponga lo que ponga, no
hace caso.
2.- El Dataset es una consulta a dos tablas mediante un Join, con lo
cual supongo que todas las opciones de mantenimiento he de hacerlas
directamente sobre el Datasource, para indicarle de qué tabla quiero
borrar el dato.
3.- Para borrar un dato utilizo:
::oOdbcDataSource:Execute("DELETE FROM TABLA WHERE CODIGO=5","Error al
borrar")
El segundo parámetro se supone que tendrí­a que salir al haber un error,
pero no sale nunca. Qué tipo de errores "Caza"?
4.- En ocasiones, dado las restricciones que tiene asignadas la propia
base de datos, me dá mensajes indicando que no se puede borrar.
Por ejemplo me dice:
Error al borrar
Class: HY000
Violation of FOREIGN KEY .....
En procedimiento ..... Lí­nea ....
¿Cómo hago para capturar yo esos errores?
He probado con nLastError y cLastError del DataSource después del
Execute(), pero siempre me devuelven 0 y "" respectivamente.
5.- Qué es la propiedad lDinamicCursors del DataSource?
Un saludico,
Fredy

[ignacio]

Fredy,
>>1.- He visto que tanto el DataSource como el DataSet tienen la propiedad
>>lDisplayErrors, que nos indica si queremos mostrar los errores tal y
>>como los genera la base de datos, sin embargo, sólo me funciona
>>modificando la del Datasource. En el Dataset, ponga lo que ponga, no
>>hace caso.
El dato lDisplayErrors se actualiza con el del DataSource cuando este es
asignado, posiblemente tengas que cambiar dicho valor después de la
asignación del DataSource al DataSet.
>>2.- El Dataset es una consulta a dos tablas mediante un Join, con lo
>>cual supongo que todas las opciones de mantenimiento he de hacerlas
>>directamente sobre el Datasource, para indicarle de qué tabla quiero
>>borrar el dato.
En principio las operaciones de UPDATE y DELETE SOLO afectan a los campos
que has modificado, por lo tanto, sino modificas los campos del JOIN no
deberías tener ningún problema. En cualquier caso siempre es posible
utilizar oDataSource:Execute( "INSERT ..." ) pero ten en cuenta que en dicho
caso el RecordSet no se actualiza automáticamente y deberás utilizar el
método RefreshCurrent() o Refresh() para actualizar el recordset.
>>3.- Para borrar un dato utilizo:
>>::oOdbcDataSource:Execute("DELETE FROM TABLA WHERE CODIGO=5","Error al
>>borrar")
>>El segundo parámetro se supone que tendría que salir al haber un error,
>>pero no sale nunca. Qué tipo de errores "Caza"?
Creo que tiene que ver con el primero punto. En cualquier caso el hecho de
que no se borre ningún registro no supone ningún error. Estoy pensando que a
lo mejor lo más comodo sería quitar la propiedad lDisplayErrors en el
DataSet pues veo que complica bastenta y no tiene mucha utilidad. Qué
opinas.
Existe una función del API de ODBC de nombre SQLRowCount() que devuelve el
número de filas afectadas por una operación de UPDATE, INSERT o DELETE. y la
acabo de implentar, en la próxima versión el Datasource tendrá una nueva
DATA de nombre 'nAffectedRows' que devolverá el número de filas afectadas en
la última llamada al método EXECUTE.
>>4.- En ocasiones, dado las restricciones que tiene asignadas la propia
>>base de datos, me dá mensajes indicando que no se puede borrar.
>>Por ejemplo me dice:
>>Error al borrar
>>Class: HY000
>>Violation of FOREIGN KEY .....
>>En procedimiento ..... Línea ....
>>¿Cómo hago para capturar yo esos errores?
>>He probado con nLastError y cLastError del DataSource después del
>>Execute(), pero siempre me devuelven 0 y "" respectivamente.
Creo que tiene más que ver con el punto 1 y la propiedad lDisplayErrors. Que
creo definitivamente voy a quitar en el Dataset. Comprueba que lDiplayErrors
este a TRUE en el DataSet. En caso contrario mandame un ejemplo que pueda
probar.
>>5.- Qué es la propiedad lDinamicCursors del DataSource?
La verdad es que se me ha colado de mi librería OZLIB, en Xailer todos los
cusrosres son estáticos, sólo lectura, y tipo forward (lectura sólo
adelante) lo que nos garantiza su correcta funcionamiento con cualquier
cliente ODBC.
Un saludo,

[fredy[1]]

Ignacio,
> En principio las operaciones de UPDATE y DELETE SOLO afectan a los campos
> que has modificado, por lo tanto, sino modificas los campos del JOIN no
> deberí­as tener ningún problema. En cualquier caso siempre es posible
> utilizar oDataSource:Execute( "INSERT ..." ) pero ten en cuenta que en dicho
> caso el RecordSet no se actualiza automáticamente y deberás utilizar el
> método RefreshCurrent() o Refresh() para actualizar el recordset.
Si utilizo el dbNavigator para borrar, me salta el error.1 que te mando.
Si después del oDataSource:Execute() le digo oDataset:RefreshCurrent()
me salta el error.2. Puede que sea porque el registro está borrado y no
puede refrescarlo.
Si pongo oDataSet:Refresh(), me actualiza los datos eliminando el
registro borrado, pero el puntero del browse se posiciona mal:
Por ejemplo: Tengo un browse con esta tabla:
NUMERO
-------
0000302
0000303
0000306
0000313
Si me posiciono en el 303 y le doy a borrar, lo borra y el browse se
queda con EL 306 en la primera lí­nea (lo hace bien)
Pero si me posiciono en el 302 y le doy a borrar, lo borra y se
posiciona en el 306 en la primera lí­nea, cuando se tení­a que haber
puesto en la 303. Digamos que hace un Skip de más.
> En cualquier caso el hecho de
> que no se borre ningún registro no supone ningún error. Estoy pensando que a
> lo mejor lo más comodo serí­a quitar la propiedad lDisplayErrors en el
> DataSet pues veo que complica bastenta y no tiene mucha utilidad. Qué
> opinas.
Realmente no es un error, pero sí­ que veo interesante el poder cazarlo
por programa para poder realizar las operaciones oportunas.
En cuanto al lDisplayErrors, creo que toda la gestión de posibles
errores tení­a que estar en el DataSource, que en definitiva es el origen
de los datos que han producido el error.
Un saludico,
Fredy

[fredy[1]]

Los ficheros de error
--

Attached files Error.1 (1.7 KB)Â Error.2 (1.9 KB)Â

[fredy[1]]

Bueno, parece que ya me va saliendo algo con la gestión de errores. Lo
que pasa es que es un poquito más liado de lo que pensaba.
De momento, hago lo siguiente:
Desactivo el lDisplayErrors del DataSource
Después del DataSource:Execute() compruebo DataSource:IsError()
Si es .t.
Pos := At( "INTEG_", DataSource:LastError )
Es decir, busco la cadena "INTEG_" que aparece en el texto del error
IF Pos == 0 //hay error pero no contiene INTEG_
MsgStop( "Error desconocido" )
ELSE
MsgStop( "Error nº: " + SubStr( DataSource:LastError, Pos, 8 ) )
ENDIF
Así­ separo los errores del tipo INTEG_16, INTEG_20, etc.. que controlan
la integridad referencial y puedo ir a una tabla con ellos para ver qué
son y qué he de hacer.
El problema que tengo es que IsError() siempre es .t. si se ha producido
un error. No se pone a .f. si el resultado de la última operación ha
sido correcta.
¿Hay algo así­ como LastOperationIsError() ?
Por otra parte, veo que :ShowErrorList() tiene una columna "# error" que
en mi caso siempre es -1.
¿Qué es exactamente y de dónde sale ese nº de error?
¿Tiene algo que ver con las Exception_ID de Firebird?
Un saludico,
Fredy

[ignacio]

Fredy,
El DbNavigator no hara otra cosa que un DataSet:Delete() y sino funciona en
principio es porque no hay clave primaria. Pero a ti te daba un error raro
construyendo la clausula WHERE. Intenta reproducir el problema usando la BD
de pruebas de FireBird y me lo mandas.
Los dos errores que me mandas son idénticos, e identicos al de otro Email
anterior. Espero que me puedas mandar un ejemplo.
Fijate que el error se produce al hacer un STR sobre un campo carácter cuyo
valor es "00010000000110" que logicamente no tiene sentido, debería ser un
campo numérico.
El uso de Refresh() es podriamos decir el último recurso ya que obliga a
traerse todo el recordset. En cualquier caso lo único que hacemos es guardar
el recno y luego hacer un sencillo DBGoto(). logicamente si el registro esta
borrado no puede volver a dicha posición, o en dicha posición abrá un
registro completamente distinto que es lo que está pasando.
La gestión de errores está hecha integramente en el DataSource, la propiedad
lDisplayErrors lo único que hace es evitar su visualización. No entiendo
como tienes tantos problemas para cazar los errores de SQL, debería ser
automático. Por favor mandame un ejemplo.
Un saludo,
"Fredy" <fredy@airtel.net> escribió en el mensaje
news:[email=MPG.1c9fabd016cc140e9896d9@news.ozs.com...]MPG.1c9fabd016cc140e9896d9@news.ozs.com...[/email]
Ignacio,
> En principio las operaciones de UPDATE y DELETE SOLO afectan a los campos
> que has modificado, por lo tanto, sino modificas los campos del JOIN no
> deberías tener ningún problema. En cualquier caso siempre es posible
> utilizar oDataSource:Execute( "INSERT ..." ) pero ten en cuenta que en
> dicho
> caso el RecordSet no se actualiza automáticamente y deberás utilizar el
> método RefreshCurrent() o Refresh() para actualizar el recordset.
Si utilizo el dbNavigator para borrar, me salta el error.1 que te mando.
Si después del oDataSource:Execute() le digo oDataset:RefreshCurrent()
me salta el error.2. Puede que sea porque el registro está borrado y no
puede refrescarlo.
Si pongo oDataSet:Refresh(), me actualiza los datos eliminando el
registro borrado, pero el puntero del browse se posiciona mal:
Por ejemplo: Tengo un browse con esta tabla:
NUMERO
-------
0000302
0000303
0000306
0000313
Si me posiciono en el 303 y le doy a borrar, lo borra y el browse se
queda con EL 306 en la primera línea (lo hace bien)
Pero si me posiciono en el 302 y le doy a borrar, lo borra y se
posiciona en el 306 en la primera línea, cuando se tenía que haber
puesto en la 303. Digamos que hace un Skip de más.
> En cualquier caso el hecho de
> que no se borre ningún registro no supone ningún error. Estoy pensando que
> a
> lo mejor lo más comodo sería quitar la propiedad lDisplayErrors en el
> DataSet pues veo que complica bastenta y no tiene mucha utilidad. Qué
> opinas.
Realmente no es un error, pero sí que veo interesante el poder cazarlo
por programa para poder realizar las operaciones oportunas.
En cuanto al lDisplayErrors, creo que toda la gestión de posibles
errores tenía que estar en el DataSource, que en definitiva es el origen
de los datos que han producido el error.
Un saludico,
Fredy

[ignacio]

Fredy,
DS:DelErrors() para borrar todos los errores después de haberlos procesado y
ya está.
Acabo de modificar las clases para que nError indique cuando sea posible el
error generado por el cliente SQL. El valor de -1 era el valor devuelto por
el API de ODBC pero sin embargo el cliente SQL ofrece más información.
Un saludo,
"Fredy" <fredy@airtel.net> escribió en el mensaje
news:[email=MPG.1c9fc4af239c02849896dc@news.ozs.com...]MPG.1c9fc4af239c02849896dc@news.ozs.com...[/email]
Bueno, parece que ya me va saliendo algo con la gestión de errores. Lo
que pasa es que es un poquito más liado de lo que pensaba.
De momento, hago lo siguiente:
Desactivo el lDisplayErrors del DataSource
Después del DataSource:Execute() compruebo DataSource:IsError()
Si es .t.
Pos := At( "INTEG_", DataSource:LastError )
Es decir, busco la cadena "INTEG_" que aparece en el texto del error
IF Pos == 0 //hay error pero no contiene INTEG_
MsgStop( "Error desconocido" )
ELSE
MsgStop( "Error nº: " + SubStr( DataSource:LastError, Pos, 8 ) )
ENDIF
Así separo los errores del tipo INTEG_16, INTEG_20, etc.. que controlan
la integridad referencial y puedo ir a una tabla con ellos para ver qué
son y qué he de hacer.
El problema que tengo es que IsError() siempre es .t. si se ha producido
un error. No se pone a .f. si el resultado de la última operación ha
sido correcta.
¿Hay algo así como LastOperationIsError() ?
Por otra parte, veo que :ShowErrorList() tiene una columna "# error" que
en mi caso siempre es -1.
¿Qué es exactamente y de dónde sale ese nº de error?
¿Tiene algo que ver con las Exception_ID de Firebird?
Un saludico,
Fredy