Conexión con Oracle

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Conexión con Oracle

Juan Pedro Pérez
Hola Sergio, gracias por tu respuesta.

Ahí te mando el log, limpio, de esta misma mañana. Muchísimas gracias.

Un saludo,

Juan Pedro Pérez

_______________________________________________
Kosmo mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo

kosmo.log (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Conexión con Oracle

Sergio Baños Calvo
Buenos días Juan Pedro.

Por lo que puedo observar en el log (aparte de un par de errores de
conexión a la tabla) es que la tabla tiene como clave primaria un campo
de tipo texto: actualmente Kosmo solo soporta tablas con claves
primarias de una única columna y numéricas (o, al menos, que tenga un
campo numérico con restricción de unicidad que pueda usar como clave)

Saludos,

Juan Pedro Pérez Alcántara escribió:

> Hola Sergio, gracias por tu respuesta.
>
> Ahí te mando el log, limpio, de esta misma mañana. Muchísimas gracias.
>
> Un saludo,
>
> Juan Pedro Pérez
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kosmo mailing list
> [hidden email]
> http://lists.saig.es/mailman/listinfo/kosmo
--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo
Reply | Threaded
Open this post in threaded view
|

Re: Conexión con Oracle

Juan Pedro Pérez
Perfecto, gracias Sergio. Definiendo la clave primaria correcta, ahora
todo funciona perfectamente.

Estas limitaciones en cuanto a la clave son, a veces y a mi parecer,
demasiado estrictas. En Quantum GIS pasa lo mismo con PostGIS. Como
desarrollador de aplicaciones, entiendo vuestra postura, ya que si no la
edición sería imposible, y seguro que hay mil cuestiones más que se me
escapan, pero muchas veces lo único que queremos es ver el resultado de
consultas sobre las que no se va a editar, y a veces, en las consultas,
es difícil llegar a definir una clave primaria tan estricta. ¿No podría
existir un modo "solo lectura", en el que la edición estuviera
completamente descartada, pero con unas restricciones de clave menos
exigentes?

Muchas gracias y seguid con el magnífico trabajo,

saludos,

Juan Pedro Pérez

On Thu, 2009-06-18 at 09:57 +0200, Sergio Baños Calvo wrote:

> Buenos días Juan Pedro.
>
> Por lo que puedo observar en el log (aparte de un par de errores de
> conexión a la tabla) es que la tabla tiene como clave primaria un campo
> de tipo texto: actualmente Kosmo solo soporta tablas con claves
> primarias de una única columna y numéricas (o, al menos, que tenga un
> campo numérico con restricción de unicidad que pueda usar como clave)
>
> Saludos,
>
> Juan Pedro Pérez Alcántara escribió:
> > Hola Sergio, gracias por tu respuesta.
> >
> > Ahí te mando el log, limpio, de esta misma mañana. Muchísimas gracias.
> >
> > Un saludo,
> >
> > Juan Pedro Pérez
> >  
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Kosmo mailing list
> > [hidden email]
> > http://lists.saig.es/mailman/listinfo/kosmo
>
> _______________________________________________
> Kosmo mailing list
> [hidden email]
> http://lists.saig.es/mailman/listinfo/kosmo


_______________________________________________
Kosmo mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo
Reply | Threaded
Open this post in threaded view
|

Re: Conexión con Oracle

Sergio Baños Calvo
Buenos días Juan Pedro.

El tema de las claves primarias es algo que tenemos pendiente de revisar
desde hace un tiempo, ya que nos hemos encontrado modelos de datos ya
existentes en algunos proyectos que tienen o claves primarias no
numéricas o claves primarias múltiples (o, incluso, tablas sin claves
primarias). En algunos casos lo hemos podido resolver mediante el uso de
un campo numérico único como ya le comenté en el anterior correo
(bastaría con añadir a la tabla un campo secuencial numérico con la
restricción de unicidad añadida si no lo tiene ya) pero esta solución no
siempre es aplicable.

Ufff, lo de QGIS con PostGIS es incluso más restrictivo, porque te
obliga a tener una clave primaria de un tipo determinado para que
funcione :-(     (int4 si no recuerdo mal): ya estuve revisando este
problema con alguien anteriormente (no recuerdo si de la lista o un
cliente de SAIG) y sucedía eso. No sé si en las últimas versiones lo
habrán corregido ya.

Tomamos nota de su sugerencia al respecto, siempre son bienvenidas ;-) .

Gracias a ti por ayudar a mejorar Kosmo.

Saludos,

Juan Pedro Pérez Alcántara escribió:

> Perfecto, gracias Sergio. Definiendo la clave primaria correcta, ahora
> todo funciona perfectamente.
>
> Estas limitaciones en cuanto a la clave son, a veces y a mi parecer,
> demasiado estrictas. En Quantum GIS pasa lo mismo con PostGIS. Como
> desarrollador de aplicaciones, entiendo vuestra postura, ya que si no la
> edición sería imposible, y seguro que hay mil cuestiones más que se me
> escapan, pero muchas veces lo único que queremos es ver el resultado de
> consultas sobre las que no se va a editar, y a veces, en las consultas,
> es difícil llegar a definir una clave primaria tan estricta. ¿No podría
> existir un modo "solo lectura", en el que la edición estuviera
> completamente descartada, pero con unas restricciones de clave menos
> exigentes?
>
> Muchas gracias y seguid con el magnífico trabajo,
>
> saludos,
>
> Juan Pedro Pérez
>
> On Thu, 2009-06-18 at 09:57 +0200, Sergio Baños Calvo wrote:
>  
>> Buenos días Juan Pedro.
>>
>> Por lo que puedo observar en el log (aparte de un par de errores de
>> conexión a la tabla) es que la tabla tiene como clave primaria un campo
>> de tipo texto: actualmente Kosmo solo soporta tablas con claves
>> primarias de una única columna y numéricas (o, al menos, que tenga un
>> campo numérico con restricción de unicidad que pueda usar como clave)
>>
>> Saludos,
>>
>> Juan Pedro Pérez Alcántara escribió:
>>    
>>> Hola Sergio, gracias por tu respuesta.
>>>
>>> Ahí te mando el log, limpio, de esta misma mañana. Muchísimas gracias.
>>>
>>> Un saludo,
>>>
>>> Juan Pedro Pérez
>>>  
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Kosmo mailing list
>>> [hidden email]
>>> http://lists.saig.es/mailman/listinfo/kosmo
>>>      
>> _______________________________________________
>> Kosmo mailing list
>> [hidden email]
>> http://lists.saig.es/mailman/listinfo/kosmo
>>    
>
>
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kosmo mailing list
> [hidden email]
> http://lists.saig.es/mailman/listinfo/kosmo
>  
--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo
Reply | Threaded
Open this post in threaded view
|

Re: Conexión con Oracle

Juan Pedro Pérez
On Thu, 2009-06-18 at 12:00 +0200, Sergio Baños Calvo wrote:

> Buenos días Juan Pedro.
>
> El tema de las claves primarias es algo que tenemos pendiente de revisar
> desde hace un tiempo, ya que nos hemos encontrado modelos de datos ya
> existentes en algunos proyectos que tienen o claves primarias no
> numéricas o claves primarias múltiples (o, incluso, tablas sin claves
> primarias). En algunos casos lo hemos podido resolver mediante el uso de
> un campo numérico único como ya le comenté en el anterior correo
> (bastaría con añadir a la tabla un campo secuencial numérico con la
> restricción de unicidad añadida si no lo tiene ya) pero esta solución no
> siempre es aplicable.
Eso mismo me pasa a mí, por eso.

> Ufff, lo de QGIS con PostGIS es incluso más restrictivo, porque te
> obliga a tener una clave primaria de un tipo determinado para que
> funcione :-(     (int4 si no recuerdo mal): ya estuve revisando este
> problema con alguien anteriormente (no recuerdo si de la lista o un
> cliente de SAIG) y sucedía eso. No sé si en las últimas versiones lo
> habrán corregido ya.

Eso mismo, int4. Con el QGIS y la PostGIS sí tengo bastante más
experiencia que con Oracle Locator. Es realmente limitante, todo el día
con campos serial artificiosos.

> Tomamos nota de su sugerencia al respecto, siempre son bienvenidas ;-) .

Gracias. Creo que es un tema importante, ya que pienso que el modelo
relacional geográfico es el pan y la sal de los SIG distribuidos, y creo
que lo principal es que los modeladores tengamos las menos restricciones
posibles a la hora de abordar el proceso de modelado. Poner campos
artificiosos, fuera de la lógica del modelo, sólo porque los programas
los necesitan para operar con la información es, para mi gusto, un
lastre en la libertad del modelador, por eso me frustra este tema
bastante. Expuse este tema también en la lista de desarrolladores de
QGIS, y por lo visto tienen planteado abordarlo en futuras versiones.
Comprendo que para echar la cosa a andar en vuestros programas (¡y vaya
si anda, evidentemente lo hecho hasta ahora no es ninguna tontería, es
un avance enorme (no más SDE, por favor)!) lo principal es comenzar por
el caso más sencillo, pero la verdad es que un tratamiento más complejo
de las claves marcaría, al menos para los modeladores, la diferencia.

Un saludo,

Juan Pedro Pérez




_______________________________________________
Kosmo mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo