A ver... si entendi bien lo que quieres es quitar un mensaje generico
y decir algo mas "especifico" en el contexto del error... e.j:
insert into tabla values (1, 'un texto');
si el servidor da un mensaje de error SQLXXXYZ, tu quieres decirle al
usuario "tal cosa ya existe en la tabla"
estoy segu
A ver... si entendi bien lo que quieres es quitar un mensaje generico
y decir algo mas "especifico" en el contexto del error... e.j:
insert into tabla values (1, 'un texto');
si el servidor da un mensaje de error SQLXXXYZ, tu quieres decirle al
usuario "tal cosa ya existe en la tabla"
estoy segu
Calabaza escribió:
> 2009/1/9 Juan Ramirez :
> >
> >> From: calali...@gmail.com
> >> Mira este hilo del archivo:
> >> http://archives.postgresql.org/pgsql-es-ayuda/2008-05/msg00385.php
> >
> > no me es funcional, porque de esa manera me obliga a crear una
> > función para cada cosa,
>
> de las fun
2009/1/9 Juan Ramirez :
>
>> From: calali...@gmail.com
>> Mira este hilo del archivo:
>> http://archives.postgresql.org/pgsql-es-ayuda/2008-05/msg00385.php
>
> no me es funcional, porque de esa manera me obliga a crear una función para
> cada cosa,
de las funciones no te vas a salvar si quieres h
> From: calali...@gmail.com
> Mira este hilo del archivo:
> http://archives.postgresql.org/pgsql-es-ayuda/2008-05/msg00385.php
no me es funcional, porque de esa manera me obliga a crear una función para
cada cosa, yo trabajo con .Net yo lo que mando es un Update a la tabla no mando
un script sq
El día 9 de enero de 2009 18:11, Jenaro Centeno Gómez
escribió:
> Por lo general las validaciones o reglas de negocio se dejan en
> procedimientos almacenados, al menos en mi caso es lo que hago, me
> ahorra mucho trabajo de andar recompilando al momento de que estas
> cambian. Con esto también ti
Por lo general las validaciones o reglas de negocio se dejan en
procedimientos almacenados, al menos en mi caso es lo que hago, me
ahorra mucho trabajo de andar recompilando al momento de que estas
cambian. Con esto también tienes tus errores personalizados ya que en
caso de error puedes utilizar e
> A lo que yo me refiero es que utilices el cliente para hacer el chequeo
> del código de error. Me imagino que tu aplicación tiene una capa de
> abstracción que se hace cargo de la base de datos?
Correcto y en efecto en la capa de Abstracción es donde tengo esa validación.
Mi intención es ver
Juan Ramirez escribió:
>
> > From: alvhe...@alvh.no-ip.org
> > Atrapa el error, verifica si es state=23505, y en ese caso ya estás
> > seguro que es una violación de restricción de unicidad (no necesitas una
> > función).
>
> Alvaro, como hago eso?¿
>
> Mi intención es hacer eso en PostGres, no
> From: alvhe...@alvh.no-ip.org
> Atrapa el error, verifica si es state=23505, y en ese caso ya estás
> seguro que es una violación de restricción de unicidad (no necesitas una
> función).
Alvaro, como hago eso?¿
Mi intención es hacer eso en PostGres, no se si te referís a realizar esa
verifica
Juan Ramirez escribió:
>
>
> Buenos días colegas,
>
> Estoy buscando hacer un cambio en los mensajes que PostGres me dá.
> Como así? te explico con un ejemplo, imaginate una tabla como la
> siguiente:
> CREATE TABLE db (codigo INT PRIMARY KEY, nombre TEXT);
>
> y al hacer insert así:
>
>
Buenos días colegas,
Estoy buscando hacer un cambio en los mensajes que PostGres me dá. Como así? te
explico con un ejemplo, imaginate una tabla como la siguiente:
CREATE TABLE db (codigo INT PRIMARY KEY, nombre TEXT);
y al hacer insert así:
insert into db select 1, 'prudencio';
que
12 matches
Mail list logo
