|
Error SQL "02000 - Data not found"
Tengo un problema bastante raro, a mi entender, con una tabla SQL, la primera vez que entro en el programa y cargo un registro que existe, lo regraba perfectamente, si vuelvo a acceder a ese registro, (seguidamente o en otro momento, pero sin salir del programa), me da el error de SQL "02000" "data not found", pero si al entrar en el registro y antes de regrabar, modifico cualquier dato, da lo mismo el que sea, me lo vuelve a regrabar perfectamente. Éste error me lo ha dado otras veces porque le he puesto al regrabar, en la sentencia SQL el campo principal (UNIQUE KEY), pero eliminandolo de la sentencia, se ha arreglado.
He probado a crear de nuevo la tabla, a ponerle a todos los campos que acepten NULL, a dejar una sola clave única de acceso, (he eliminado las otras "KEY" que tenía, que, de momento no se usaban), y alguna que otra cosa más, pero no hay manera de descubrir el por qué del error. Ando ya desesperado, alguna sugerencia, porque lo único que me queda es borrar tabla y programa y empezar desde cero y no quisiera. Gracias y un saludo.- |
Josber, parece tema de COMMIT. Echale un ojo a ver si lo haces bien, y que la configuracion del ODBC este bien. ;)
|
Gracias, Kuk, acabo de hacer una prueba, que era la que me faltaba, poniéndole al principio de la subrutina de regrabar, nada más entrar, un COMMIT, para "liberar" la BD, y nada, exactamente igual y la configuración del ODBC, debe estar bien porque con otras tablas, funciona sin problemas.
Un saludo.- |
Josber, tienes que hacer COMMIT despues de la modificacion. Si no lo haces, la modificacion queda en Pending, pero no se le aplica a la BBDD. Todo lo que es INSERT, DELETE y UPDATE hay que hacer COMMIT despues siempre.
|
Hola Amigos, a mi me paso algo parecido con una tabla de access, el tema era que se perdían registros sin saber porque, luego de unas 5000 ideas distintas, elimine la tabla, la cree nuevamente, elimine el control del programa, lo asigne nuevamente, recompile y anduvo, nunca supe cual fue la razón.
Saludos :banned: :banned: |
Cita:
Hrm la tabla la he borrado y creado varias veces, incluso con otro nombre pero nada y el control no puedo puedo borrarlo, no existe porque es SQL embebido. Gracias y un saludo.- |
Hrmcobol, en tu caso, me parece que era entonces culpa de la configuraicon del control.
Josber, pega aqui el codigo de INSERT en la tabla, y el codigo de SELECT, los 2 completos. |
Aquí tienes, (lo hago en dos post, porque en uno ólo no me deja):
Select Código COBOL:
|
Insert
Código COBOL:
Gracias a [email protected] |
Josber, varias cosas. Yo lo que mas he usado ha sido DB2, asi que te voy a decir desde ese prisma cosas a mejorar: el INTO va antes que el FROM. El * (asterisco) no se aconseja usarlo jamas en programas. Tampoco se aconseja llamar de misma forma las variables y los cmapos de la tabla.
En cuanto a tu problema, como tienes definido el campo PRONOM en la tabla, y como la variable PRONOM en la WORKING? |
¿PRONOM?, ¿No te referirás a PROCOD?
Código COBOL:
Código:
'PROCOD' decimal(5,0) unsigned NOT NULL COMMENT 'NUM. PROVEEDOR',Un saludo.- |
Josber, los campos VARCHAR son campos compuestos, y en COBOL se representan asi:
Código COBOL:
Los niveles 49 deben ser 49 y no otro. Todos los VARCHAR contienen 2 bytes demas, al principio del campo en formato binario donde se indica la longitud, que deberiamos informar segun la longitud que vayamos a usar (de 1 a 40 en este caso). De hecho es la ventaja de los VARCHAR. En cuanto a lo otro, para los DECIMAL debes usar COMP-3 (o que es lo mismo PACKED-DECIMAL), ademas en la tabla es UNSIGNED : Código COBOL:
Pero joe, todo esto son mas bien temas de rendimiento (menos lo del COMP-3). Pero entiendo que en otros sitios te funcion con DECIMAL numerico simple de COBOL? Ha de haber una conversion automatica, puede que en este caso falla por algo. Intenta cambiarlo por COMP-3 a ver que tal... Si no, ya no se me ocurre nada mas.... :piensa: :( |
No sabía lo del nivel 49 y que los VARCHAR eran campos compuesto, los puedo cambiar por TINYTEXT, aunque lo malo que tiene éste campo es que no pueden contener NULL, ni un valor declarado de inicio. En cuanto al UNSIGNED, si les quito el signo en la WORKING, a la hora de compilar, me dice que han de ser con signo obligatoriamente, si te pusiera la declaración de la WORKING, verías que todos los campos numéricos llevan signo, (CÓDIGO, TARIFA, GRUPO, NÚMERO DE CUENTA, etc.., y es una mier...).
Un saludo.- Añadido despues de 2 horas 52 minutos Confirmado Kuk, si pones COMP-3 y le quitas el signo, al compilar da el siguiente error: FORM-PROVEEDORES-SQL WORKING-STORAGE(7) : JMN2898I-S The host variable of a binary, external decimal, or internal decimal item must contain the symbol S. FORM-PROVEEDORES-SQL VIENE-DE-FORM-PRO-INI(85) : JMN3175I-S The USAGE of sending item 'PROCOD' in the STRING statement must be DISPLAY. Un saludo.- |
Josber, que yo sepa los VARCHAR pueden ser NULL... Pero estas cosas varian a veces, yo como uso DB2, es de lo que más sé. Lo mismo pasa con el signo, DB2 lo permite perfectamente sin signo.
Metele signo y COMP-3. Tambien prueba con COMP-4 en vez de COMP-3 y a ver que tal ;) |
A ver, aunque hace ya unnnnn montón de tiempo de ésto, estaba buscando otra cosa y me he topado con ello.
Al final solucioné el error, nada tan sencillo como mover a ZEROS o SPACES, (lo que corresponda), todas las variables definidas en la WORKING que atañen al fichero que se va a actualizar, ¡¡OJO!!, es muy importante, NO SIRVE hacer un INITIALIZE, no funciona, o por lo menos a mí no me funcionó, fue hacer eso y se acabó el problema. Un salu2 a [email protected] |
| La franja horaria es GMT +2. Ahora son las 14:46. |
Powered by: vBulletin, Versión 3.8.7
Derechos de Autor ©2000 - 2026, Jelsoft Enterprises Ltd.