** NORMAS DEL FORO **
Inicio del foro Inicio del foro > Access y VBA > Access y VBA
  Mensajes nuevos Mensajes nuevos RSS - Access 2016 cierra con nuevo registro
  Preguntas frecuentes Preguntas frecuentes  Buscar en el foro   Eventos   Registro Registro  Iniciar sesion Iniciar sesion

Access 2016 cierra con nuevo registro

 Responder Responder
Autor
Mensaje
ibcaja Ver desplegable
Nuevo
Nuevo


Unido: 29/Julio/2019
Localización: España
Estado: Sin conexión
Puntos: 9
Opciones de entrada Opciones de entrada   Gracias (0) Gracias(0)   Cita ibcaja Cita  ResponderRespuesta Enlace directo a este mensaje Tema: Access 2016 cierra con nuevo registro
    Enviado: 29/Julio/2019 a las 08:44
Hola, llevo unos días atascado con un problema del que no consigo salir.
He hecho una aplicación para generar tickets de ventas. Hay dos tablas una de cabecera de ticket (numero ticket, fecha, modo de pago, total) y otra tabla de detalle de ticket (numero ticket, articulo, cantidad, precio).
El formulario principal va vinculado a la tabla de cabecera y dentro hay un subformulario vinculado a la tabla de detalle de ticket.
Cuando empiezo a meter datos en el suformulario de detalle guardo la cabecera con:

Me.Parent.Dirty =False

Una vez meto una o varias lineas, tengo un botón de Nuevo Ticket en el formulario principal que al clicar hace un:

DoCmd.GoToRecord acDataForm, "FormTicket", acNext

y aquí es donde tras unas milésimas de espera se cierra completamente Access 2016 x64 , sin ningún error, ni aviso.

En el Visor de Eventos puedo ver fallo de un modulo VBE7.DLL

Si pongo un punto de interrupción en la orden anterior y vuelvo a ejecutar tengo un error
"2046 - La acción o comando 'IrARegistro' no está disponible ahora"
Lo cual tiene más sentido, aunque tampoco acabo de ver el motivo.

He intentado hacerlo con una macro, o con el asistente de botones y ocurre lo mismo, un crash.

Pensando que puede estar corrupta la BBDD o formularios he intentado el método de decompilar. He rehecho tablas y copiado los datos con csv, consultas copiadas con SQL, y formularios e Informes mediante los métodos SaveAsText y LoadFromText. Pero con el mismo resultado.

Espero pueden darme alguna orientación al tema. Gracias y Saludos
Arriba
happy Ver desplegable
Moderador
Moderador


Unido: 29/Enero/2005
Localización: España
Estado: Sin conexión
Puntos: 3074
Opciones de entrada Opciones de entrada   Gracias (1) Gracias(1)   Cita happy Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 29/Julio/2019 a las 18:12
La verdad es que no tengo ni idea de por qué te puede estar pasando eso, ni tampoco tengo access 2016 ni tampoco el de x64.

Pero por si pudiera funcionar ... sustituye el

Me.Parent.Dirty = False

por el método más estandard de

DoCmd.RunCommand acCmdSaveRecord

A ver si te sirve de algo ... (pero ya digo, esto es un poco a ciegas, por si la instrucción Me.Parent.Dirty = False pudiera influir en el crash que te da)
Saludos,

Juan M. Afan de Ribera
Arriba
ibcaja Ver desplegable
Nuevo
Nuevo


Unido: 29/Julio/2019
Localización: España
Estado: Sin conexión
Puntos: 9
Opciones de entrada Opciones de entrada   Gracias (0) Gracias(0)   Cita ibcaja Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 29/Julio/2019 a las 22:19
Gracias por tu respuesta. El problema es que se ejecuta dentro de un evento BeforeInsert del subformulario, de ahí lo del 'Parent' y según creo 'DoCmd.RunCommand acCmdSaveRecord' se ejecutaría para el registro del subformulario, no el padre.

Además no solo crashea con un acNext, si no con cualquier movimiento del registro: First, Previous, Last. Tal como indica el error 2046.

Durante el desarrollo de esta aplicación, a partir de cierto momento, he ido sufriendo este tipo de errores unas veces, y crasheos otras que he ido solventando volviendo a versiones anteriores guardadas. Pero ya ni eso me funciona, tengo que volver a versiones muy antiguas y seria mejor empezar de cero. Y ya llevo perdido mucho tiempo es estos retrocesos, llevo semanas de retraso para algo que tampoco es tan grande.

Ejecutando en otros PC's (con la misma versión de Office) también ocurren, en el mio además con todas las actualizaciones al día.

No tengo mucha experiencia con Access y no sé si son habituales este tipo de corrupciones y como se suelen solucionar. Aunque no descarto que tenga algo en el código que lo provoque, por lo pronto voy a intentar cambiar de versión de Office.

Saludos.




Arriba
Mihura Ver desplegable
Administrador
Administrador
Avatar

Unido: 06/Mayo/2005
Localización: En la dehesa
Estado: Sin conexión
Puntos: 11055
Opciones de entrada Opciones de entrada   Gracias (1) Gracias(1)   Cita Mihura Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 30/Julio/2019 a las 08:26
Se me ocurren algunas cosas a probar:

- haz un decompile de la aplicación
- prueba a 'actualizar' el formulario parent en un procedimiento que esté directamente colgado en él, desde el subformulario lanza ese procedimiento en vez del 'SaveRecord'
Jesús Mansilla Castells.
Saludos desde Móstoles.

Access Aplicaciones
Tecsys.es
Arriba
happy Ver desplegable
Moderador
Moderador


Unido: 29/Enero/2005
Localización: España
Estado: Sin conexión
Puntos: 3074
Opciones de entrada Opciones de entrada   Gracias (1) Gracias(1)   Cita happy Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 30/Julio/2019 a las 09:52
Además de lo que te dice Jesús (Mihura), ten en cuenta que antes de liarte con renovar el Office, decompilar, crear una nueva base de datos limpia a partir de la que ya tienes, y como tú bien dices, es posible que el problema venga del código o más bien, del planteamiento en el que ejecutas ese código.

Quiero decir que todo lo que dices que ocurre tiene que ver con eventos de dos formularios diferentes y acciones que también disparan eventos, aunque tú no los llames explícitamente (el hecho de guardar registro puede disparar otros eventos, y el ir a un nuevo registro también dispara eventos). Esto puede complicarse enormemente (o no, dependiendo de lo que estés implementando). Podría ser que el método que estés empleando para hacer lo que sea que hagas con estas acciones que describes tuviera un resultado circular o provocara una serie de peticiones que Access no es capaz de resolver, y por eso se cierra "a lo bestia" después de una determinada instrucción. Tú comentas que desde el evento BeforeInsert lanzas una acción al formulario padre (guardar el registro) que podría desencadenar evento/s en ese otro formulario y al final, como digo, Access no puede resolver satisfactoriamente. Esto podría provocar un intento de invasión de memoria no autorizada o de llegar al límite de cantidad de memoria, o algo así ... y el sistema le dice a Access "hasta aquí has llegao amigo, ciao!".

A lo mejor me estoy enrollando mucho y los tiros no van por ahí eh?, sinceramente no lo sé. En todo caso creo que antes de liarte con cambios de versión de Office y cosas así, podrías hacer una pequeña prueba modificando el método en que haces las cosas y atacando el tema desde un punto de vista muy claro, sin atajos (si es que los utilizas, que no se, ya digo)

Hace ya tiempo que el tema de los posibles bugs o fallos lo dejé como último último recurso, ya que la gran mayoría de las veces los problemas vienen por un mal uso o un uso equivocado de métodos, instrucciones, etc.

Smile
Saludos,

Juan M. Afan de Ribera
Arriba
ibcaja Ver desplegable
Nuevo
Nuevo


Unido: 29/Julio/2019
Localización: España
Estado: Sin conexión
Puntos: 9
Opciones de entrada Opciones de entrada   Gracias (0) Gracias(0)   Cita ibcaja Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 30/Julio/2019 a las 10:49
Gracias por vuestras repuestas.
Instalé la versión de 32 bits, y ahora funciona sin problemas, por lo pronto. Me quedo en esta versión porque además pretendo hacer consultas a una BBDD en Visual Fox Pro y parece ser que no hay drivers de 64 bits.

No descarto lo que dice happy, pero por mas que repasé el código y secuencia de eventos no vi nada raro, cosa normal cuando es tu código y con mi inexperiencia.

Publicado originalmente por Mihura Mihura escribió:

... prueba a 'actualizar' el formulario parent en un procedimiento que esté directamente colgado en él, desde el subformulario lanza ese procedimiento en vez del 'SaveRecord'


Aunque parece que resolví el problema, me interesa tu propuesta, intuyo lo que pretendes, pero no sé bien en que procedimiento hacer eso y como llamarlo.

Saludos.

Editado por ibcaja - 30/Julio/2019 a las 10:52
Arriba
Mihura Ver desplegable
Administrador
Administrador
Avatar

Unido: 06/Mayo/2005
Localización: En la dehesa
Estado: Sin conexión
Puntos: 11055
Opciones de entrada Opciones de entrada   Gracias (0) Gracias(0)   Cita Mihura Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 30/Julio/2019 a las 11:14
El procedimiento lo llamas en el formulario Padre:

Public Sub MiRutina()
    .
    .
End Sub


Y lo llamas desde el subformulario:

Me.parent.Mirutina
Jesús Mansilla Castells.
Saludos desde Móstoles.

Access Aplicaciones
Tecsys.es
Arriba
Maverick2019 Ver desplegable
Nuevo
Nuevo


Unido: 10/Junio/2019
Localización: Madrid
Estado: Sin conexión
Puntos: 48
Opciones de entrada Opciones de entrada   Gracias (0) Gracias(0)   Cita Maverick2019 Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 30/Julio/2019 a las 11:39
Hola
Ten encuenta al elegir la versión de Office (32 ó 64 bits) si es realmente la que necesitas:
Microsoft no recomienda que uses la versión de 64 bits a menos que te encuentres en alguna de las situaciones que indican.

Salu2,
Arriba
ibcaja Ver desplegable
Nuevo
Nuevo


Unido: 29/Julio/2019
Localización: España
Estado: Sin conexión
Puntos: 9
Opciones de entrada Opciones de entrada   Gracias (0) Gracias(0)   Cita ibcaja Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 31/Julio/2019 a las 17:27
Publicado originalmente por Mihura Mihura escribió:

El procedimiento lo llamas en el formulario Padre:

Public Sub MiRutina()
    .
    .
End Sub


Y lo llamas desde el subformulario:

Me.parent.Mirutina

No se me ocurrió lo de llamar desde un procedimiento de formulario a otro de uno distinto. De todas maneras no funciona para estos comandos:

DoCmd.RunCommand acCmdSaveRecord

DoCmd.RunCommand acCmdDeleteRecord
          
Error 2046 en ambos casos. Al final empleé el método del Dirty para el guardado y el DELETE con SQL para el borrado. No sé si son menos ortodoxos.

Saludos.
Arriba
Maverick2019 Ver desplegable
Nuevo
Nuevo


Unido: 10/Junio/2019
Localización: Madrid
Estado: Sin conexión
Puntos: 48
Opciones de entrada Opciones de entrada   Gracias (0) Gracias(0)   Cita Maverick2019 Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 31/Julio/2019 a las 17:37
Hola
Sí no me equivoco,  la propiedad Dirty es para saber sí hay cambios pendientes de guardado, no para guardarlos.
Que me corrijan sí me equivoco...

Salu2,
Arriba
happy Ver desplegable
Moderador
Moderador


Unido: 29/Enero/2005
Localización: España
Estado: Sin conexión
Puntos: 3074
Opciones de entrada Opciones de entrada   Gracias (0) Gracias(0)   Cita happy Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 31/Julio/2019 a las 17:55
Hola Maverick, sí, la propiedad Dirty es para eso que dices, pero como esa propiedad es de lectura/escritura, al decirle Me.Dirty = False, se guarda el registro que haya en [Me].

A efectos de depuración paso a paso, si uno va pulsando F8 en las sucesivas líneas de código, cuando se encuentra con instrucciones del tipo DoCmd.RunCommand acCmdSaveRecord, aparece el error de "no se puede ejecutar esta instrucción ..." (creo que es ese error 2046). Pero ¿por qué aparece ese error?

Si os fijáis en la instrucción DoCmd.RunCommand acCmdSaveRecord, si la intentamos "traducir" será algo como "Ejecuta comando.comando "guarda el registro". Eso está muy bien, pero esa instrucción no dice qué registro se ha de guardar, ni de qué origen de datos. Sólo dice que guarde el registro (podrías tener más de un origen de datos abierto en la base de datos en ese momento, no?). Por eso es que salta ese error al pulsar F8, porque esa instrucción necesita que haya un origen de datos que tenga el foco en ese momento (normalmente será un formulario con origen de datos apuntando a una tabla o consulta actualizable). Y en ese momento, ¿quién tiene el foco? Ningún origen de datos lo tiene, sino la ventana de código VB tiene el foco. Por eso falla, porque no sabe donde dirigir la instrucción de "guardar registro" acCmdSaveRecord.

En cambio la instrucción Me.Dirty = False, también provoca que se guarde el registro, pero esta instrucción sí que indica el origen de datos en el que se ha de guardar el registro, es decir el [Me], que normalmente será un formulario con un origen de datos definido. Por eso la depuración paso a paso no lanza ningún error cuando pasa por encima de esa línea con esa instrucción.

También de ahí que le dijera en este hilo que cambiara la instrucción Me.Dirty = False por DoCmd.RunCommand acCmdSaveRecord, porque quién sabe, a lo mejor estaba incidiendo de alguna manera en los eventos que se producían.

Pero si ya se ha resuelto al cambiar de versión ...



Saludos,

Juan M. Afan de Ribera
Arriba
Maverick2019 Ver desplegable
Nuevo
Nuevo


Unido: 10/Junio/2019
Localización: Madrid
Estado: Sin conexión
Puntos: 48
Opciones de entrada Opciones de entrada   Gracias (0) Gracias(0)   Cita Maverick2019 Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 31/Julio/2019 a las 17:59
Como siempre, Juan, es un placer leerte.
Salu2,

Arriba
ibcaja Ver desplegable
Nuevo
Nuevo


Unido: 29/Julio/2019
Localización: España
Estado: Sin conexión
Puntos: 9
Opciones de entrada Opciones de entrada   Gracias (0) Gracias(0)   Cita ibcaja Cita  ResponderRespuesta Enlace directo a este mensaje Enviado: 31/Julio/2019 a las 20:59
Gracias happy. El error sale en modo ejecución normal, dentro de un procedimiento del formulario con el registro activo a guardar. Incluso añadí un 'DoCmd.RunCommand acCmdSelectRecord' y lo sigue produciendo.

Saludos.
Arriba
 Responder Responder
  Compartir tema   

Ir al foro Permisos de foro Ver desplegable