No me deja modificar el recordset de una vista en la version 2005 de SQL.

¿como hiciste la migración? eso suena a que te faltan claves primarias


Saludos
Miguel Egea
"LaCo" wrote in message
news:
Hola:

Me ha surgido un problema al cambiar de versión de Microsoft SQL de la
2000 a la 2005.
Resulta que tengo una aplicación implementada en VB6 que accede a una
base de datos para obtener información. Uno de esos accesos se realiza
a un vista formada a partir de varias tablas utilizando un recordset.
El caso es que cuando intento modificar un valor del recordset en la
versión nueva (la 2005), no me deja dándome el siguiente error:

Error '-2147217887 (80040e21)'

He comprobado las restricciones que impone el SQL Server con respecto a
modificar una vista
(http://msdn2.microsoft.com/es-es/li...80800.aspx) y en un
principio las cumplo. Lo extraño es que en la versión antigua no me
da ningún error y los cambios en la base de datos se efectuan sin
problema.

¿alquien ha tenido algún problema parecido? Estoy un poco ya
desesperado, he mirado en muchos sitios y no he podido dar con la
solución.

Gracias por adelantado y saludos.
LaCo

P.D: He pegado el mismo post en el foro microsoft.public.es.vb ya que
realmente no se donde colocarlo. De todas formas el problema viene a
ser de la base de datos ya que la aplicación funciona correctamente y
he descartado que sea problema de código.

hola:

La migración pues la hice un tanto a la ligera, sin pensar en las
consecuencias. Creé la base de datos y posteriormente restauré a
partir de la copia de seguridad.

No creo que sea problema de que falten cosas (o eso me parece), porque
tengo una versión antigua y voy comparando con la nueva y en principio
parece que está todo igual.

De todas formas creo que es más problema del VB6 por lo de cambiar el
valor al recordset, aunque no descarto que haya que hacer algo en el
sqlserver.

Voy perdidísimo!

Miguel Egea wrote:

¿como hiciste la migración? eso suena a que te faltan claves primarias


Saludos
Miguel Egea

revisa lo de las primary keys y nos cuentas

"LaCo" wrote in message
news:
hola:

La migración pues la hice un tanto a la ligera, sin pensar en las
consecuencias. Creé la base de datos y posteriormente restauré a
partir de la copia de seguridad.

No creo que sea problema de que falten cosas (o eso me parece), porque
tengo una versión antigua y voy comparando con la nueva y en principio
parece que está todo igual.

De todas formas creo que es más problema del VB6 por lo de cambiar el
valor al recordset, aunque no descarto que haya que hacer algo en el
sqlserver.

Voy perdidísimo!

Miguel Egea wrote:

¿como hiciste la migración? eso suena a que te faltan claves primarias


Saludos
Miguel Egea

Ya puesto, comento un poco como esta el tema.
La vista - vCandidatos - se crea a partir de la tabla tCandidatos:

SELECT dbo.tCandidatos.can_codigo, dbo.tCandidatos.can_nombre,
...

Estos, si que me deja modificarlos.
Además de tener también columnas procedentes de otras tablas como...

(SELECT cae_estudio
FROM dbo.tCandidato_Estudios
WHERE (cae_candidato = dbo.tCandidatos.can_codigo)
AND (cae_prioridad = 1)) AS can_estudio1,

que es la que intento cambiar y no me deja. El sql server me produce el
siguiente error:

"No se puede actualizar ni insertar la vista o función 'vCandidatos'
porque contiene un campo derivado o constante"

La tabla tCandidato_Estudios:
- cae_nivel (PK)
- cae_candidato (PK, FK de tCandidato)
- cae_estudios(PK, FK de tEstudios)

tEstudios
- est_codigo (PK)

tCandidatos
- can_codigo (PK)

¿Alguna idea de porqué puede fallar y no dejar editar el
can_estudio1?

No puedo probarlo ahora, pero la verión vieja, el 2000, creo que no me
dejaba tampoco cambiarlo a pelo pero sí en el codigo de VB6, asignarle
otro valor al recordset y lo único que he hecho es cambiar de version
de sql server para que el código deje de funcionar.

¿que opinas?

Miguel Egea wrote:

revisa lo de las primary keys y nos cuentas

pues parece que no cumples alguna de las restricciones para hacer vistas
actualizables, aunque puedes usar instead of triggers quizá:

Updatable Views
You can modify the data of an underlying base table through a view, as long
as the following conditions are true:

Any modifications, including UPDATE, INSERT, and DELETE statements, must
reference columns from only one base table.

<Miguel Egea, esto creo que es lo que no cumples>
The columns being modified in the view must directly reference the
underlying data in the table columns. The columns cannot be derived in any
other way, such as through the following:
</Miguel Egea, esto creo que es lo que no cumples>

An aggregate function: AVG, COUNT, SUM, MIN, MAX, GROUPING, STDEV, STDEVP,
VAR, and VARP.


A computation. The column cannot be computed from an expression that uses
other columns. Columns that are formed by using the set operators UNION,
UNION ALL, CROSSJOIN, EXCEPT, and INTERSECT amount to a computation and are
also not updatable.


The columns being modified are not affected by GROUP BY, HAVING, or DISTINCT
clauses.


The previous restrictions apply to any subqueries in the FROM clause of the
view, just as they apply to the view itself. Generally, the Database Engine
must be able to unambiguously trace modifications from the view definition
to one base table. For more information, see Modifying Data Through a View.

If the previous restrictions prevent you from modifying data directly
through a view, consider the following options:

INSTEAD OF Triggers

INSTEAD OF triggers can be created on a view to make a view updatable. The
INSTEAD OF trigger is executed instead of the data modification statement on
which the trigger is defined. This trigger lets the user specify the set of
actions that must happen to process the data modification statement.
Therefore, if an INSTEAD OF trigger exists for a view on a specific data
modification statement (INSERT, UPDATE, or DELETE), the corresponding view
is updatable through that statement. For more information about INSTEAD OF
triggers, see Designing INSTEAD OF Triggers.


Partitioned Views

If the view is a partitioned view, the view is updatable, subject to certain
restrictions. When it is needed, the Database Engine distinguishes local
partitioned views as the views in which all participating tables and the
view are on the same instance of SQL Server, and distributed partitioned
views as the views in which at least one of the tables in the view resides
on a different or remote server.

For more information about partitioned views, see Creating Partitioned
Views.




Saludos
Miguel Egea

"LaCo" wrote in message
news:
Ya puesto, comento un poco como esta el tema.
La vista - vCandidatos - se crea a partir de la tabla tCandidatos:

SELECT dbo.tCandidatos.can_codigo, dbo.tCandidatos.can_nombre,
...

Estos, si que me deja modificarlos.
Además de tener también columnas procedentes de otras tablas como...

(SELECT cae_estudio
FROM dbo.tCandidato_Estudios
WHERE (cae_candidato = dbo.tCandidatos.can_codigo)
AND (cae_prioridad = 1)) AS can_estudio1,

que es la que intento cambiar y no me deja. El sql server me produce el
siguiente error:

"No se puede actualizar ni insertar la vista o función 'vCandidatos'
porque contiene un campo derivado o constante"

La tabla tCandidato_Estudios:
- cae_nivel (PK)
- cae_candidato (PK, FK de tCandidato)
- cae_estudios(PK, FK de tEstudios)

tEstudios
- est_codigo (PK)

tCandidatos
- can_codigo (PK)

¿Alguna idea de porqué puede fallar y no dejar editar el
can_estudio1?

No puedo probarlo ahora, pero la verión vieja, el 2000, creo que no me
dejaba tampoco cambiarlo a pelo pero sí en el codigo de VB6, asignarle
otro valor al recordset y lo único que he hecho es cambiar de version
de sql server para que el código deje de funcionar.

¿que opinas?

Miguel Egea wrote:

revisa lo de las primary keys y nos cuentas