Hola a todos.
Tengo (tenemos, en la empresa en donde trabajo) una serie de dudas, casi
todas relacionadas con la implantación (posible) de la base de datos
cumpliendo reglas de integridad referencial, usando tablas SQL, etc...
Voy, por partes.
1. Datos DATALINK. Nos gustaría implementar el tipo DATALINK en algún
campo. De momento, no nos hace falta que se verifique la existencia del
objeto referido, pero sí que la sintaxis del enlace sea correcta. En general
no tengo problemas, pero, resulta que, pretendo que guarde enlaces en los
que está el símbolo "!".
Según veo en los manuales, no se puede incluir ese símbolo en un campo
DATALINK. Si bien, el enlace, como es lógico, funciona perfectamente en un
navegador.
¿Sabe alguien si hay alguna manera de hacerlo? (y que no sea sustituirlo
por otro carácter o series de caracteres, por favor)
Por cierto, ese link es de Filenet, en donde se usa habitualmente el
símbolo "!".
2. Campos IDENTITY. Los empezamos a utilizar hace un tiempo. Todo parecía
maravilloso, hasta que, vimos que con un CPYF teníamos problemas.
Bueno, en realidad los tiene la utilidad que tenemos para promoción entre
entornos.
Ésta, lo que hace es (resumiendo) copiar el objeto antiguo, con CPYF o
CRTDUPOBJ duplicando datos. Luego crea el nuevo (en este caso, con una
sentencia CREATE TABLE, que adjunto). A continuación, hace un CPYF de los
datos del backup al recién creado. Esto no da problemas.
El problema es que cuando se pretende añadir un nuevo registro en la
tabla recién creada nos da clave duplicada. Ya sea con Insert o con un
programa, o cpyf, lo que sea (si es clave duplicada, es clave duplicada,
¿no?).
Parece como si no hubiera actualizado el índice del Identiity, al hacer
el copy desde el backup a la tabla recién creada.
Supongo que la siguiente pregunta es: ¿por qué utilizas CPYF en vez de
sentencias SQL Insert?. Bueno, es que, en realidad, como decía, el problema
lo tenemos con la utilidad de promoción entre entornos. Que emplea el CPYF.
Adjunto la sentencia SQL para crear una tabla (de ejemplo):
CREATE TABLE PRUIDE(
Cod_cliente FOR CLTKYC NUMERIC(9, 0)
NOT NULL DEFAULT 0,
Clave for CLAVEC INT
GENERATED ALWAYS AS IDENTITY
(START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE NO
CYCLE NO ORDER CACHE 20),
-- Se define como PRIMARY KEY el campo autogenerado
PRIMARY KEY(Clave)
)
3. Respecto a la creación de claves foráneas. Resulta que, según parece,
si creas una, de la tabla B que apunte a la A, ésta debe estar libre, no
debe tener bloqueo alguno. En caso contrario no se crea la regla.
¿Hay alguna manera de crear esta regla aunque el objeto "padre" esté
bloqueado?
Os cuento que utilizamos sentencias SQL para crear las relaciones (así
como las tablas y todos los objetos relacionados). Somo muy novatos, y, como
tantos, estamos en fase de transformación de DDS a SQL. Pero éste es uno de
los problemas que se nos ha planteado (y tenemos sin solución aún).
Entiendo la lógica de esa norma, pero, no se si de alguna manera, se
puede evitar.
Tengo más dudas, pero no es cuestión de abusar.
A ver si alguien me puede iluminar en estos temas.
Muchas gracias por la molestia de leeros este mail.
Un saludo
Íñigo Redín
Helvetia Seguros
España
____________________________________________________
Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
Forum.Help400 © Publicaciones Help400, S.L.
