Logo_Access_global_380x114Favicon_Access_global_180x180Logo_Access_global_380x114Logo_Access_global_380x114
  • Home
  • University
    • Destellos formativos
  • Labs
  • TV
  • Secciones
    • El mundo de Access
    • Explorando VBA
      • Artículos sobre VBA
      • Un trocito de código
    • Entrevistas
      • Profesionales de Access
    • El rincón de Excel
    • Bases de datos
      • MS SQL
      • MySQL
      • postgreSQL
      • SQLite
    • Clases magistrales
    • Utilidades hechas con Access
  • Access en el mundo
  • ¿Quiénes somos?
  • Cómo colaborar
  • Eventos
✕
            No hay resultados Mostrar todos los resultados
            Access: movernos por los registros través de un listbox
            02/03/2022
            Diseño: crea tus propios botones de navegación
            03/03/2022
            Mostrar todos

            Access y el conflicto de escritura

            Publicado por Luis Viadel
            Categorías
            • El mundo de Access
            Etiquetas
            • Access
            • Conflicto escritura

            Es posible que trabajando con bases de datos SQL y Access, te hayas encontrado con el aviso “Conflicto de escritura” y no has sido capaz de resolverlo.

            Este no es un tema nuevo. Si hacemos una simple búsqueda, observaremos que este problema está en la red desde hace muchos, mucho años. Aún así, es difícil encontrar soluciones reales al mismo. En este artículo vamos a analizar todas las posibles causas y soluciones, tanto las que personalmente ha sufrido como programador como con otras que he ido encontrando mientras intentaba resolver mi problema.

            Causa 1  : varios usuarios intentan escribir a la vez en el mismo registro.

            Si acudimos a la ayuda de Microsoft para entender este problema nos encontramos con la explicación más “simple y lógica” que se refiere a que dos usuarios, con sendos formularios, acceden a los datos concretos de un registro a la vez. El primer usuario establece un bloqueo que cuando el segundo usuario intenta hacer cambios, salta el mensaje de error.

            La probabilidad de que esto ocurra en una pequeña organización, os la podéis imaginar. No obstante, debemos pensar que es posible, por lo que intentaremos solucionarlo tal y como nos indica la web de ayuda. Para ello disponemos de dos métodos:

            1. Establecer la propiedad RecordLocks del formulario en registro editado.
            2. Agregar “Docmd.RunCommand acCmdSaveRecord” al procedimiento “OnDeactivate” de ambos formularios para forzar a que guarde el registro cuando se desactive el formulario.

            Si después de hacer todo esto no nos vuelve a aparecer el mensaje de error, ¡genial! Porque ya está solucionado y puedes dejar de leer este artículo.

            El problema viene cuando sigue apareciendo el mensaje una y otra vez.

            Me voy a enfocar en PostgreSQL que es la base de datos con la que trabajo, pero por lo que he podido ver durante este tiempo, otras bases de datos SQL también tienen este problema o parecido. Así, podrás utilizar esta información para guiarte en la solución del problema en estas bases de datos.

             

            Causa 2: un recordset ha quedado abierto.

            Si dejamos un recordset abierto, Access estará interpretando que alguien tiene bloqueado el recordset para su escritura, por lo que al intentar hacer cambios, nos mostrará el mensaje.

            Para solucionarlo revisaremos nuestra programación para comprobar que en cualquier acceso a datos (ADO o DAO) no dejamos recordsets abiertos. Siempre que abrimos un recordset, debemos cerrarlo:

            Set rst=CurrentDB.openrecordset(“MiTabla”)

                        …

            rst.close

            Set rst=nothing

             

            Causa 3: ha quedado abierta otra instancia de Access

            Tras un error, una instancia de Access ha quedado abierta y nosotros, al ejecutar nuestra aplicación, abrimos una segunda instancia sobre el mismo archivo.

            Para comprobarlo, iremos al “Administrador de Tareas” y cerraremos las instancias que no estemos utilizando.

             

            Causa 4: valores NULL y Cadena vacía

            Access dispone de dos alternativas para indicar que no hay un registro en un campo: la cadena vacía y Null. Podemos escribir el valor de un campo como “”, por lo que Access interpretará que es una cadena de longitud 0, o podemos escribir “Null” y Access interpretará que el campo está vacío. PostgreSQL, por su parte,  interpreta ambos casos como Null.

            Para comprobar que no es la causa de nuestro problema o simplemente solucionarlo, deberemos comprobar que todas las cadenas vacías se almacenan como “Null”.

             

            Causa 5: campo fecha y hora

            El campo fecha y hora de PostgreSQL (timestamp) tiene una precisión de microsegundos, mientras que el campo fecha/hora de Access tiene una precisión de milisegundos, por lo que al hacer la comparación envía el mensaje de error que nos ha traído hasta aquí.

            Si has utilizado la función Now() en Access para rellenar un campo fecha del tipo mencionado, es muy probable que te aparezca el error por la razón que antes hemos expuesto.

            La solución pasa por utilizar campos de fecha y hora con una precisión menor, que iguale la precisión de Access. Podemos utilizar timestamp (3) para una precisión de milisegundos o timestamp (0) para una precisión de segundos. Deberemos fijarnos muy bien al diseñar nuestra base de datos y si nuestras fechas son normales, sin altas precisiones, lo mejor es trabajar con una precisión de segundos.

            Si estamos construyendo una nueva base de datos nueva es sencillo seguir estas recomendaciones, pero ¿y si ya está creada y repleta de registros como seguramente es tu caso? Te indico unos sencillos pasos para que puedas solucionar el problema.

             

            -- Creamos una columna temporal en nuestra tabla, con la precisión requerida.
            ALTER TABLE mitabla ADD COLUMN micampotemp timestamp(0) without time zone NULL;
            
            -- Copiamos los valores originales en el nuevo campo que hemos creado.
            UPDATE mitabla SET micampotemp = micampo::timestamp(0);
            
            -- Borramos el campo original, después de haber comprobado que los datos han sido copiados.
            ALTER TABLE mitabla DROP COLUMN micampo;
            
            -- Renombramos la nueva columna con el nombre original
            ALTER TABLE mitabla RENAME COLUMN micampotemp TO micampo;
            

            Causa 6: campo Bit

            La causa que presento a continuación, no se me ha presentado personalmente pero me ha parecido conveniente incluirla. Hace referencia a que hemos introducido un campo tipo Bit que no está inicializado, tenemos un campo bit en nuestra tabla y no tiene ningún valor, por lo que al vincularlo con Access, si la tabla no tiene ningún campo, al intentar introducir cualquier registro nos dará el error. Por el contrario, en una tabla que ya tenga datos, el error se mostrará tanto en INSERT como en UPDATE, ya que Access necesita mostrar un valor para ese campo y la base de datos no dispone de él, por lo que intenta escribir dos valores al mismo tiempo. (fuente Web4x4.es)

            Para poder resolverlo deberemos asignar un valor predeterminado (0 o 1) al campo bit y por último volver a vincular la tabla o actualizar la vinculación.

             

            Causa 7: campos calculados

            En la misma fuente que el anterior encontramos otra posible situación con los campos real, decimal, etc… que dependen de fórmulas. Podemos encontrar el típico campo calculado importe (unidades x precio) y al intentar escribir en otro campo del registro nos muestra el error ya que el campo calculado es posterior al UPDATE y Access no sabe cuál es el correcto.

            La solución pasa por crear un campo timestamp que incluya el momento de la actualización para que Access distinga entre ambos momentos y por último volver a vincular la tabla o actualizar la vinculación.

            Como observarás, las causas pueden ser muy diversas, por lo que espero haberte sido de utilidad y si conoces algún caso distinto a los que enumero en este artículo, indícalo y lo incluiremos como problema/solución del mismo.

            Créditos imagen: Pixabay

            Actualización del 09/03/2022

            Se me ha dado una nueva circustancia que quiero añadir al artículo y hace referencia a los formatos numéricos de nuestra base de datos y el tratamiento que hace Access de ellos.

            En Access el campo tipo "number" puede dividirse en los siguientes tipos:

            Byte: se usa para enteros comprendidos entre 0 y 255. El requisito de almacenamiento es 1 byte.

            Entero: se usa para enteros comprendidos entre -32.768 y 32.767. El requisito de almacenamiento es 2 bytes.

            Entero largo: se usa para enteros comprendidos entre -2.147.483.648 y 2.147.483.647. El requisito de almacenamiento es 4 bytes.

            Single: se usa para valores numéricos de punto flotante que van de -3,4 x 1038 a 3,4 x 1038 y hasta siete dígitos significativos. El requisito de almacenamiento es 4 bytes.

            Double: se usa para valores numéricos de punto flotante que van de -1,797 x 10308 a 1,797 x 10308 y hasta quince dígitos significativos. El requisito de almacenamiento es de 8 bytes.

            Decimal: se usa para valores numéricos que van desde -9,999... x 1027 a 9,999... x 1027. El requisito de almacenamiento es de 12 bytes.

            En las bases de datos SQL los datos numéricos difieren un poco de esta lista que hemos enumerado para Access. Si intentamos almacenar un dato numérico proveniente de una base de datos SQL, debemos de analizar la compatibilidad de ambos campos.

            Si existe un error en los tipos, también se nos muestra el mensaje de error de "conflicto de escritura". Para resolverlo en PostgreSQL, deberemos seleccionar el tipo correcto de datos. Podemos utilizar el mismo sistema que para las fechas, como hemos comentado anteriormente.

            Compartir
            4
            Luis Viadel
            Luis Viadel

            Entradas relacionadas

            26/11/2021

            ¿Es una opción Microsoft Access para mi negocio?


            Leer más

            2 Comments

            1. Chea dice:
              02/03/2022 a las 7:12 pm

              Hay otra posibilidad de que salga un mensaje parecido a ese , aunque no es exactamente el mismo: Cuando estás escribiendo en un formulario (la propiedad Dirty es true) y modificas algo del mismo origen de datos mediante código. En ese caso, la solución es es escribir Me.Dirty = false o DoCmd.RunCommand AccmdSaveReveRecord antes de ejecutar el código que modifica la tabla.

              Responder
            2. Luis Viadel Pruñonosa dice:
              03/03/2022 a las 8:15 am

              Gracias Chea por tu comentario. SI te parece bien, ilustraremos tu ejemplo en un destello.

              Responder

            Deja una respuesta Cancelar la respuesta

            Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

            ETIQUETAS

            Access API BD Botones ComboBox Consultas CountOfLines CStr Diseño DoCmd Excel Exportar Fecha FileSystemObject Filtros For Each...Next Formulario Formularios Funciones Funciones de dominio GetFolder GetWindowRect Google maps Informes InStr Jose Bengoechea Kill Left Listbox Mid Módulos Node ProcCountLines Procedimientos ProcOfLine References Ribbon RunCommand Seguridad Split SysCmd Tablas TreeView VBA VBIDE

            ÚLTIMAS ENTRADAS

            • 0
              ¿Mis procedimientos tienen tratamiento de errores?
              21/03/2023
            • 0
              Moda, mediana y algo más
              20/03/2023

            ¿QUIERES PUBLICITAR TU EMPRESA AQUÍ?

            SUSCRÍBETE A NUESTRO
            NEWSLETTER

            Recibirás información puntual sobre el mundo de Access y VBA

            ¡Próximamente!

            Promovemos el uso de Access y de la programación en VBA en todo el mundo

            Centro de conocimiento


            Toda la sabiduría de los mejores programadores de Access y VBA a tu alcance.

            Legal

            Política de privacidad

            Condiciones de uso

            Condiciones del redactor

            ®Access Global 2021 | All right reserved
                      No hay resultados Mostrar todos los resultados