Access - ERROR DE COMPILACION - EL ARGUMENTO NO ES OPCIONAL

Buenas tardes.

Tengo una tabla llamada EXP en la que se registran expedientes de las cosas que se realizan a los clientes. Tiene de campos, entre otros, dos que se llaman S y D. En la S va siempre una U y en la D el numero del departamento del 1 al 8. Una vez que esos expedientes se han realizado y pasado factura por ello se modifica la S por una W y la U por un 11. He creado una consulta para que seleccione solo los W 11. Y con esa consulta un informe. Hasta ahí todo correcto. Ahora quiero que una vez copiado o sacado ese informe, esos campos cambien para no mezclarlo con las nuevas bajas. Y se modificaría la W por F y el 11 por 99. Yo pensé en hacer un botón que cuando le diera lo cambiara y puse esta función.


Pero al darle al botón me aparece ese error ERROR DE COMPILACION - EL ARGUMENTO NO ES OPCIONAL y me marca el error en el título, es decir Private Sub Comando13_Click()

No sé que error puede haber ahi o como puedo hacer eso que quiero. No entiendo mucho de access y todo lo que hago o intento hacer es buscando e investigando por mi cuenta.

Muchas gracias de antemano y un saludo

Access (y todo aquello que sea 'programable') tien su particular idioma, no hables con Access como si fuera Excel o SQL Server o …. habla con Access en su lenguaje.

Marca esa línea porque la siguiente dudo que la entienda y el resto … quizás lo intente.

Lo primero:
Donde están los datos ?

No es lo mismo con los datos en un formulario, que en sus orígenes (el método es diferente),
Tampoco es lo mismo cambiarlos de forma unitaria (eso parece por lo expuesto) que cambiarlos de una sola vez (también con un click)

En Access ( y en VBA ) la asignación de un valor no necesita un 'Set' basta la asignación simple.
Lo de ' Update Exp ' creo que necesita ampliar la información sobre el, en principio Access intentara entenderlo y lo de 'update' o es una función o esta fuera de contexto (y por ello creerá que falta algo).

Si tengo un campo en el formulario y deseo consultar su valor :

IF [nombre del campo] = [valor a comparar] Then …..

Si los datos a verificar son dos, se duplica el numero de elementos y pueden darse dos posibilidades:

Que se cumplan los dos términos (se utiliza AND) que sea suficiente con que se cumpla uno (se utiliza OR)

En este caso parece que lo caorrecto es que se cumplan ambos y la constuccion seria asi:


EL original:


Lo que podría funcionar:



Asumo que un campo se llame 's' y otro 'd' son sinónimos de los campos reales (yo los he denominado [campo1] y [campo2]

Notas....
Access interpreta que un carácter es un numero (si el carácter es numérico) sin necesidad de indicárselo
ejemplo: Variable_A = 5

Access interpreta y trabaja con caracteres alfanuméricos indicándolo con comillas dobles (y excepcionalmente con comillas simples)
ejemplo: Variable_A = "Buenos días"

Si se trata de fechas en modo texto, o se le indica que es una fecha o … efectúara la operación matemática (ojo a las fechas, en VBA : en formato americano)
ejemplo:Variable_A = #1/20/2020# ( el 20 de enero del año 2020 … en el idioma natal de sus creadores)

Variable_A es cualquier objeto manipulable y del tipo adecuado al tipo de dato a recibir (un cuadro de texto, una variable, una propiedad …)

Desconozco donde intentas buscar información, pero la mas fiel que podrás encontrar la tienes 'debajo' de la tecla F1 y después … hay montones de cursos gratuitos (muchos de ellos a niveles muy asequibles, otros mas avanzados).

Otra fuente de conocimiento … los ejemplos (en forma de plantillas) que acompañan a Access

Buenos días.

He probado lo que me has dicho pero me aparece otro error "ERROR DE COMPILACION: BLOQUE IF SIN END IF" y me vuelve a marcar Private Sub Comando13_Click() como error.

Después he probado:


Y ahora me marca el error '-2147352567 (80020009)' en tiempos de ejecución: No se puede asignar un valor a este objeto. Cuando le doy a depurar me marca el error en [S] = "F"

El único que conoce lo real tras ese código (los tipos de datos etc …) es el diseñador de la aplicación, el resto …. quizás con mas datos nos aproximaríamos, de entrada se trabaja con supuestos y los supuestos : son simples teorías posiblemente destinadas al fracaso.

Has aplicado lo cómodo: copiar y pegar manipulando lo mínimo y eso solo acertaría si el original se basase en datos concretos (conocer los tipos de campo implicados por ejemplo).

Cuando se comienza en este entorno, en múltiples ocasiones se cae en errores conceptuales por no preocuparse de conocer un poco los objetos con los que se interactúa.

Un clásico: suele suceder con los combo-box por no tener en cuenta que lo que se observa no tiene porque ser el dato real (casi siempre se utiliza un ID y se muestra la descripción).

Si Access no acepta como dato para el objeto 'S' un texto será porque NO es un campo de tipo STRING (texto), será numérico o simplemente no es un cuadro de texto, pudiera ser que el tipo de objeto 'no es lo que parece' (y probablemente llegaríamos al combo)

Antes de programar (manipular los objetos) se debería tener claro la funcionalidad para la que ha sido diseñado y así darle un uso correcto.

Asóciese a iniciarse en la conducción de un vehículo:
.- hay que tener muy claro cual cada pedal y su funcionalidad en la practica.
.- lo mismo con 'el palito' (la palanca de cambio), cada posición y en un orden determinado implica un tipo de movimiento (su sentido y/o la velocidad asociada).

El campo S era de texto corto con un limite de 1 caracter, y el campo D era numerico. He modificado la tabla y he puesto ambos campos como texto corto con sus 255 caracteres que viene predeterminado, he creado de nuevo la consulta y el informe y me sigue dando el mismo error.

No estas aplicando la lógica, Access trabaja sobre una maquina para lo que 'todo son números' y por eso es 'cuadriculado' a la hora de actuar.

Para verificar si un campo 'en su origen' admite un tipo de dato, es tan elementalmente sencillo como acudir a la tabla dar valores a sus campos (por lo menos a aquellos que se indico en su diseño que eran 'requeridos') y guardarlo, si funciona en principio se sabe que ese dato es valido.

Si el campo (originalmente) solo permitía un carácter, de lo único que cabria preocuparse es de que lo que se le quiera asignar tenga un solo carácter (los espacios muchas veces pasan desapercibidos: pero existen).

Si el otro campo era numérico (porque se podría utilizar para cálculos) y se cambia a texto, podrá haber consecuencias, si solo se le indico 'numérico' porque su contenido se preveía que serian números … es indiferente y quizás sea mejor un campo de texto (si no hay problemas con el orden).

Desconozco 'donde' se esta aplicando esa aportación, se presupone que en UN FORMULARIO que se basa en la tabla que contiene los campos.
Si se esta utilizado un formulario, pero 'su origen' es una consulta en la que intervenga mas de un origen de datos (varias tablas o mezclas de tablas y consultas) hay que utilizar el mismo método que antes con la tabla, se ejecuta esa consulta y se 'intenta' modificar ese campo.

En muchas ocasiones, si se utilizar consultas con varios orígenes de datos, Access (a causa de las relaciones entre esos orígenes) no puede precisar exactamente a que registro y de que tabla tiene que modificar y en aras de no hacerlo mal, no lo permite, se ha de buscar un método que permita definir como únicos a los registros para que se permita una verdadera interactuación.

Como anexo a lo anterior ….
.- solo se trata de conocer las reglas de trafico para para poder circular por las vías publicas (con carnet, sin el …. )

Nota:
Que es eso del informe?... un informe no sirve para cambiar ningún origen, lo utiliza paro no lo modificara (o no debería modificarlo en una programación correctamente diseñada), espero que lo de informe sea un error y se trate de un formulario (o ambos hemos perdido el tiempo)

No tengo ningún formulario relacionado con lo que te estoy diciendo. Te vuelvo a explicar lo que tengo hecho a ver si así me explico mejor.

Esta es la tabla que tengo creada. En el campo S siempre va una U y en la D el departamento que realiza la tarea. Una vez que la tarea ha finalizado y se ha cobrado por ello se pone en la D una W y en la D un 11.



De esa tabla creé esta consulta para que seleccione solo los expedientes con W 11.



Y de esta consulta cree un informe para registrar los expedientes dados de baja.



Y ahora una vez hecho ese informe, lo guardo, que contiene los expedientes dados de baja ese día.

Ahora bien la próxima vez que yo de de baja expedientes, si vuelvo a poner W 11 se me mezclarían con los anteriores, entonces quería insertar un botón en el informe para los que ya tienen W 11 cambien, la W por F y el 11 por 99. O bien hacer algo que pueda cambiar eso una vez generado el informe.

En lo referente a formulario, como puedes comprobar con lo que he te comentado y con las imágenes, no tengo ninguno, no sé si quizás sea conveniente crear un formulario y crear ahí el botón, que al pulsarlo se cambien esos campos.

He creado un formulario a ver si así funcionaba o a ver como quedaba



La fórmula que me diste funciona. El problema está ahora en que solo se actualizan esos datos si estoy en la página donde esta el W 11, es decir, que tendría que ir registro por registro actualizando y dándole al botón. Lo suyo sería darle al botón y que actualizara todos los registros que tienen W 11 a la vez.

Retrocedamos al principio, cada objeto tiene su sentido, si todos fueran idénticos …. para que tendríamos tablas, consultas, formularios, informes y ….

Un informe solo sirve para presentar resultados, para INTERCTUAR con los datos se utilizan los formularios, datos que SOLO se guardan en las tablas.

Un ejemplo a titulo comparativo: las marchas del vehículo (uno corriente) la primera para iniciar el movimiento, las siguientes en función de la velocidad o potencia que se precise, pero en un orden, no se pasa de la primera a la quinta o se reduce de la quinta a la segunda.

Una tabla ===> almacén de datos
Una consulta ==> combina tablas para obtener un conjunto de esos datos
Un formulario ==> Manipula esos datos o los crea o … es un medio de interactuación
Un Informe ==> Presenta los resultados de los datos manipulados mediante formularios.

Si quieres manipular datos: utiliza un formulario

SI se quiere hacer una actualización de los datos … una consulta (existen unas que son de actualización) y llegar a ella desde la actual de selección es sencillo:
.- en la parte superior (la cabecera de la consulta en su vista diseño) estará seleccionado el tipo 'seleccionar', se cambia (un click) a consulta de 'actualizar'
.- aparece una nueva línea con el titulo 'actualizar a:'
.- bajo cada campo a modificar (en tu caso los mismos que utilizas para seleccionar) los nuevos valores
.- la guardas

Cuando la ejecutes, actualizara con un click todos los campos y todos los registros que se le indiquen (y normalmente en un instante costo)

Una programación diseñada de forma 'normalizada' abriría un formulario para presentar esos datos, desde el se ejecutaría (con un click) el informe y opcionalmente habría otro botón para ejecutar esa consulta de actualización, pues un informe se puede 'visualizar sin imprimir' y al visualizarlo se podrá apreciar si es correcto o no, lo mejor es dejara como optativa la actualización de esos datos

.- (las cajas de cambios de los vehículos 'solo' tienen una marcha atrás … ¿porque será?

Nota:
.- duplica la actual de selección, una consulta solo sabe hacer una cosa
.- pero puede haber cinco copias (cada una con su nombre, aun tienes letras libres en el abecedario)
.- y cada copia hacer una cosa (visualizar, borrar, modificar, insertar …...

Listo. Ahora sí he conseguido lo que quería, además que te dice la cantidad de registros que se van a actualizar y te pregunta si los quieres actualizar, está genial.

Muchas gracias por tu ayuda y paciencia.