Recordset no actualizables.

Las consultas de datos agregados (como DISTINCT o GROUP BY) no son actualizables, ya que el motor no
puede saber qué registro "original" (de los que han dado lugar al registro "agregado") es el que
queremos actualizar; supón que tenemos 30 clientes, 25 de la provincia "Asturias" y 5 de la
provincia "Madrid"; por ejemplo:

rstProvincias.Open "SELECT DISTINCT Provincia FROM Clientes ORDER BY Provincia"
rstProvincias.Edit
rstProvincias!Provincia = "Galicia"
rstProvincias.Update

Ésta consulta no es actualizable, ya que el motor de la base de datos no puede determinar cuál de
los 25 clientes debe actualizar

Según MSDN:
[...] Queries with aggregated data are not updatable
Summary (GROUP BY), UNION, DISTINCT, and crosstab queries are never updatable. Queries joined to one
or more summary queries are not updatable, even if you do not attempt to modify fields from an
otherwise updatable table

Un saludo!

Rubén Vigón
Microsoft MVP Visual Basic

Gracias por contestar, pero las consultas a las que me refiero, no son
consultas con grupos, sino consultas sencillas de tablas, normalmente
relacionadas con ellas.

Gracias de nuevo.











"Rubén Vigón" escribió en el mensaje
news:#

Las consultas de datos agregados (como DISTINCT o GROUP BY) no son

actualizables, ya que el motor no

puede saber qué registro "original" (de los que han dado lugar al registro

"agregado") es el que

queremos actualizar; supón que tenemos 30 clientes, 25 de la provincia

"Asturias" y 5 de la

provincia "Madrid"; por ejemplo:

rstProvincias.Open "SELECT DISTINCT Provincia FROM Clientes ORDER BY

Provincia"

rstProvincias.Edit
rstProvincias!Provincia = "Galicia"
rstProvincias.Update

Ésta consulta no es actualizable, ya que el motor de la base de datos no

puede determinar cuál de

los 25 clientes debe actualizar

Según MSDN:
[...] Queries with aggregated data are not updatable
Summary (GROUP BY), UNION, DISTINCT, and crosstab queries are never

updatable. Queries joined to one

or more summary queries are not updatable, even if you do not attempt to

modify fields from an

otherwise updatable table

Un saludo!

Rubén Vigón
Microsoft MVP Visual Basic

Hola Antonio.
Además de lo que te comenta Rubén, y en base a lo mismo, tu tabla a actualizar
tiene que tener una clave primaria, un campo que hace que cada registro quede
indentificado. Sí incluyes esa columna en tus consultas, el motor de la base de
datos sabrá en cada momento que registro actualizar.
Para eso puedes o elegir una columna que cumpla con ese requisito (columna
única) o poner por ejemplo, un campo autonumérico, teniendo en cuenta que su
función será esa, marcarte una clave primaria, y no sería aconsejable que la
usaras para otra cosa (identificador de factura, por ejemplo) al no poder
controlar los huecos.
También puedes coger un conjunto de columnas para generar tu clave primária,
pero lo más sencillito es que fuera una sola.

Salu2.
José Mª Fueyo
[MS-MVP Access]

¡Urgente! Boletín de seguridad MS03-039
http://www.microsoft.com/spain/tech...9-USER.asp

¡Actualizate!

También, si las consultas están basadas en varias tablas relacionadas y
sobre todo relaciones Varios a Varios pueden generar recordsets no
actualizables dependiendo del tipo de relación y según que campos se hayan
incluido...

Saludos,
Martín


"José Mª Fueyo" escribió en el mensaje
news:

Hola Antonio.
Además de lo que te comenta Rubén, y en base a lo mismo, tu tabla a

actualizar

tiene que tener una clave primaria, un campo que hace que cada registro

quede

indentificado. Sí incluyes esa columna en tus consultas, el motor de la

base de

datos sabrá en cada momento que registro actualizar.
Para eso puedes o elegir una columna que cumpla con ese requisito (columna
única) o poner por ejemplo, un campo autonumérico, teniendo en cuenta que

su

función será esa, marcarte una clave primaria, y no sería aconsejable que

la

usaras para otra cosa (identificador de factura, por ejemplo) al no poder
controlar los huecos.
También puedes coger un conjunto de columnas para generar tu clave

primária,

pero lo más sencillito es que fuera una sola.

Salu2.
José Mª Fueyo
[MS-MVP Access]

¡Urgente! Boletín de seguridad MS03-039

http://www.microsoft.com/spain/tech...9-USER.asp

¡Actualizate!

Ok, tomo nota. Gracias a todos.








"Martín" <centralbib @hotmail.com> escribió en el mensaje
news:

También, si las consultas están basadas en varias tablas relacionadas y
sobre todo relaciones Varios a Varios pueden generar recordsets no
actualizables dependiendo del tipo de relación y según que campos se hayan
incluido...

Saludos,
Martín


"José Mª Fueyo" escribió en el mensaje
news:
> Hola Antonio.
> Además de lo que te comenta Rubén, y en base a lo mismo, tu tabla a
actualizar
> tiene que tener una clave primaria, un campo que hace que cada registro
quede
> indentificado. Sí incluyes esa columna en tus consultas, el motor de la
base de
> datos sabrá en cada momento que registro actualizar.
> Para eso puedes o elegir una columna que cumpla con ese requisito

(columna

> única) o poner por ejemplo, un campo autonumérico, teniendo en cuenta

que

su
> función será esa, marcarte una clave primaria, y no sería aconsejable

que

la
> usaras para otra cosa (identificador de factura, por ejemplo) al no

poder

> controlar los huecos.
> También puedes coger un conjunto de columnas para generar tu clave
primária,
> pero lo más sencillito es que fuera una sola.
>
> Salu2.
> José Mª Fueyo
> [MS-MVP Access]
>
> ¡Urgente! Boletín de seguridad MS03-039
>

http://www.microsoft.com/spain/tech...9-USER.asp

>
> ¡Actualizate!
>
>