NOMBRES DE OBJETOS, CAMPOS Y

CONTROLES

Índice de contenido
INTRODUCCIÓN................................................................................................................................2
NOMBRES DE OBJETOS..................................................................................................................3
NOMBRES DE CAMPOS...................................................................................................................4
NOMBRES DE CONTROLES............................................................................................................6
PARA FINALIZAR ESTE ARTÍCULO...............................................................................................7

1
Visítame en http://bit.ly/NckAccess
 INTRODUCCIÓN
Este artículo nace debido a que, en estos años de ver bases
y bases de usuarios, he podido comprobar que la utilización
de nombres en objetos, campos y controles es algo que
“usuarios inexpertos” descuidan. Descuidan por
desconocimiento, básicamente. Es decir, que ese
“descuidan” no lo digo con ninguna implicación negativa.

Partamos del punto en que debéis entender que todo lo que

propondré en este artículo es, simplemente, eso, una proposición.
Que nadie lo entienda como una “verdad absoluta”, dado que un
simple vistazo en Internet nos permitirá descubrir diferentes
maneras de hacer las cosas, todas ellas perfectamente válidas. Os
ruego que tengáis esto en mente mientras leáis este artículo (si
sois capaces de llegar al final... je, je...).

El principal problema, desde mi punto de vista, es la “estrechez de horizontes” a la hora de

crear una base de datos. Me explico a través de un ejemplo:

Un usuario sin conocimientos de Access decide hacer una inmersión en esta aplicación y crea
una base de datos simple. “La base de datos tiene que ser lo más clara posible”, piensa (y con
razón). Y es cuando crea unas tablas así:

TABLA CON INFORMACIÓN CLIENTES

TABLA PARA DAR DE ALTA PRODUCTOS

Y, por extensión, la cosa funciona perfecta y crea los demás objetos de Access siguiendo la
misma mecánica:

CONSULTA QUE FILTRA CLIENTES POR PROVINCIA

INFORME DE PRODUCTOS QUE ESTÁN DE ALTA

En la primera tabla, por ejemplo, crea, entre otros, los siguientes campos

[Nombre del cliente]

[Domicilio del cliente]
[Domicilio de verano del cliente]
[Número de DNI del cliente]

Y sobre esta tabla crea un formulario llamado FORMULARIO CON INFORMACIÓN DE CLIENTES,
donde le aparecen los anteriores campos, y, además, descubre los controles y empieza a
añadir cuadros combinados, cuadros de lista, botones de comando...

La base de datos funciona a la perfección., con lo que las necesidades están perfectamente
cubiertas.

Pasan unos meses (por ser optimista) y nuestro usuario aprende algunas funciones de Access,
aprende algunos rudimentos de VBA y, por seguir siendo optimista, aprende algo de SQL.
¡Fantástico!

Entonces la pregunta es: ¿qué es lo que va a pasar?

2
Visítame en http://bit.ly/NckAccess
 NOMBRES DE OBJETOS
Los nombres de objetos deberían ser nombres cortos y lo
más descriptivos posible. No habría que utilizar acentos en
dichos nombres (insisto, por última vez, en que todo lo que
diré son recomendaciones).

Quien conozca alguno de mis ejemplos verá que yo

antepongo la letra:

T: Tabla
C: Consulta
F: Formulario
R: Informe

Es decir, que yo escribiría como nombre de tabla:

TClientes (o, abreviado aún más, TCli)

o, si fuera necesario por los motivos que sean,

TClientesAlta

De esta manera, si yo os digo que he escrito RInventario no necesito deciros que me estoy
refiriendo a un informe.

Hay otros sistemas, como anteponer los siguientes prefijos para designar los objetos:

tbl: Tabla
qry: Consulta
frm: Formulario
rpt: Informe

Volviendo a nuestro estimado usuario de Access, supongamos que quiere crear un código VBA
para manipular un subformulario en un formulario. Entonces debería escribir:

Forms![FORMULARIO CON INFORMACIÓN DE CLIENTES].[SUBFORMULARIO CON

INFORMACIÓN DE ACTIVIDADES DE CLIENTES].Form.[Cuadro Combinado 234].Visible=False

Y si lo anterior se repite muchas veces en el código pues... para “tirarse de los pelos”.

Si yo escribo lo siguiente:

Forms!FCli.subFrmActCli.Form.cboAct.visible=False

¿No creéis que resulta un poco más eficiente?

Otro problema que podría aparecer sería cuando, al ejecutar el código, nos salta un error
diciendo que no se encuentra el subformulario. ¡Pero si está ahí! ¡Lo estoy viendo! Y después
de un buen rato de mirar y mirar nos percatamos que el nombre real del subformulario es
[SUBFORMULARIO CON INFORMACION DE ACTIVIDADES DE CLIENTES]. ¿No es el mismo?
Pues no, porque escribimos INFORMACION sin acento gráfico (¡anda, se nos olvidó ese
acento!).

Si “sabemos” que a los nombres de objetos NUNCA les ponemos acentos, ese problemilla que
nos ha consumido diez minutos (por ser de nuevo optimista) de búsqueda del error... “¡plof:

3
Visítame en http://bit.ly/NckAccess
desapareció!”

Alguno pensará: “Pero cuando se carga el formulario queda

muy 'feo' que el usuario vea esa especie de criptograma
'FCliAct', ¿no?”.

Pues la verdad es que sí. Pero eso tiene una solución muy
sencilla: si sacamos las propiedades del formulario y nos
vamos a la pestaña Formato, a la propiedad “Título”, ahí
podemos escribir el nombre que queramos. Una vez escrito,
y cuando abramos nuestro formulario, veremos que su
título es el que hemos indicado en esa propiedad.

NOMBRES DE CAMPOS
Lo explicado para los nombres de objetos en el punto anterior, en cuanto a la extensión de los
mismos, es perfectamente aplicable a los nombres de campos.

Imaginaos que nuestro querido usuario aprende a utilizar una SQL de inserción de datos. Para
programar la ejecución de una sentencia SQL de este tipo debería escribir:

miSql=”INSERT INTO [TABLA CON INFORMACIÓN CLIENTES] ([Nombre del cliente], [Domicilio
del cliente], [Número de DNI del cliente]) VALUES (‘Pepito Pérez’, ‘C/ de la Zarzamora, 23’,
“123456789Z’)”

¡Y eso que sólo he utilizado tres campos!

Si se hubieran escrito los nombres reducidos la SQL podría haber quedado así:

miSql=”INSERT INTO TInfCli (NomCli, DirCli, IdCli) VALUES (‘Pepito Pérez’, ‘C/ de la
Zarzamora, 23’, “123456789Z’)”

Ventajas:

• Reducción del tamaño de la SQL y mejora de su legibilidad

• Si no ponemos espacios en los nombres no es necesario la utilización de corchetes (=
escribimos menos)

En definitiva, ponemos los nombres de campos reducidos y sin espacio entre palabras

Nombre del cliente --- NomCli

Algunas veces nos podemos encontrar con tablas diferentes que utilizan nombres de campos
que son muy parecidos. Lógicamente, podríamos escribir:

IdCli

en todas esas tablas para el campo que recoja el identificador del cliente. Ahora bien, eso
podría causar confusión tanto en el código VBA (y SQL) como, por ejemplo, si necesitamos
fijar el campo de relación entre un formulario principal y un subformulario.

La solución a este problema puede pasar por añadir algún tipo de identificador relacionado con
la tabla. Por ejemplo, si yo escribo como nombres de campos:

IdCliNac
IdCliExt

4
Visítame en http://bit.ly/NckAccess
no os costaría nada en absoluto identificar a qué tabla pertenecen si yo os digo que mis tablas
se llaman:

TCliNacionales
TCliExtranjeros

Prosigamos. Nuestro querido usuario ha escrito los

siguientes nombres de campos:

[% Desviación sobre ventas]

[Suma envases & productos]

A continuación vuelve a escribir un código VBA y... ¡sorpresa! Saltan errores por todas partes.
¿Qué es lo que está pasando?

Pues que está utilizando caracteres reservados de VBA en los nombres de campos. Y el código,
al intentar leer los nombres de campos, interpreta el tanto por ciento (%) y el ampersand (&)
como partes de código y no como nombre de campo.

Moraleja: no podemos utilizar caracteres reservados en los nombres de campos. ¿Y cuáles son
esos caracteres reservados? Pues son los siguientes:

Nombre carácter Carácter

Barra /
Interrogación final ?
Exclamación final !
Asterisco *
Guión -
Comilla simple ‘
Comilla doble “
Punto y coma ;
Dos puntos :
Símbolo del dólar $
Almohadilla #
Ampersand &
Porcentaje %

Nota: aprovecho la ocasión para comentaros, como curiosidad, que si en alguna ocasión, con
vuestro código VBA, tenéis problemas con algún carácter en los valores de los campos (ojo, en
los valores de los campos, no en los nombres), podéis solucionar ese problema utilizando
variables temporales. Os recomiendo este excelente artículo de Chea aquí o, si os lo queréis
bajar en pdf, aquí.

De nuevo nuestro usuario nos dirá ahora: “Pero si yo hago un formulario basado en una tabla
los nombres de los campos quedan muy “feos”. Efectivamente, un nombre de campo llamado
“PorcVtasCli” queda muy poco elegante de cara a un usuario de la base de datos. Pero,
¡tranquilos! No hace falta “matarse” cambiando etiquetas de campos.

¿Por qué? Porque cuando estamos creando el campo en la tabla, en la parte inferior donde

5
Visítame en http://bit.ly/NckAccess
están las propiedades del campo, tenemos una propiedad llamada “Título”.

Si en esa propiedad escribimos el nombre que queremos

que vea el usuario, a la hora de crear el formulario sobre la
tabla, Access “buscará” primero si hay algún valor en esa
propiedad y si lo encuentra pues lo utiliza como nombre de
etiqueta. ¡Y listos!

NOMBRES DE CONTROLES
Finalmente, todo lo dicho en los puntos anteriores es de
perfecta aplicación aquí. Si insertamos un cuadro
combinado en un formulario podemos observar que Access
nos escribe como nombre predeterminado “Cuadro
CombinadoXX”, donde XX es un número.

Manejar esa nomenclatura es farragoso en VBA, principalmente pos dos motivos:

• El que ya os he comentado de “pesadez” de escritura

• El problema que nos aparece para identificar el control si el código nos marca un error.

Imaginaos que nuestro usuario tiene un código en un módulo asociado a un formulario así:

…
Private Sub Cuadro_Combinado23_Click()
‘Código
End Sub
Private Sub Cuadro_Combinado37_Click()
‘Código
End Sub

Private Sub Cuadro_Combinado78_Click()

‘Código
End Sub

Private Sub Cuadro_Combinado97_Click()

‘Código
End Sub
…

Y, lo anterior, con siete cuadros combinados más.

Salta el error en el “Cuadro_Combinado37”. ¿A cuál de los diez cuadros combinados se está

refiriendo?

Tendríamos que irnos al formulario en vista diseño, localizar cuál es el cuadro combinado 37, y
arreglarlo. Os aseguro que como tengamos muchos errores de código eso es muy “time
consuming”.

Y ahora multiplicad ese problema por 15 formularios... je, je...

Existe una nomenclatura para los controles. Os pongo a continuación la correspondiente a los
controles más comunes:

6
Visítame en http://bit.ly/NckAccess
 Nombre control Prefijo
Cuadro de texto txt

Etiqueta lbl
Cuadro combinado cbo
Cuadro de lista lst
Casilla de verificación chk
Botón de opción opt
Marco de opciones mrc
Botón de comando cmd
Objeto OLE ole

Es decir, que si yo creo un cuadro combinado para recoger información sobre el campo [%
Desviación Aplicado] lo que haría sería:

• Uno: cambiar el nombre de ese campo a, por ejemplo y simplemente, “PorcDesviacion”

(ojo, ¡sin acento!).
• Dos: llamar, por ejemplo, a mi cuadro combinado cboPorcDesv.

Y, si me permitís, os haré un pequeño comentario personal respecto a una letra española: la

eñe.

Yo no utilizo esta letra en ninguna parte de Access. “¿Por qué?”, me preguntaréis. Pues
básicamente por dos motivos:

• Primero, porque si, por los motivos que sean, utilizamos un teclado no español vamos a
encontrarnos con que no tenemos esa letra.

• Segundo, porque si pedimos ayuda a algún amigo no español (lo que implica, en el
fondo, que no va a tener un teclado español) se va a “tirar de los pelos” cuando tenga
que “lidiar” con esa “letrita”... je, je...

PARA FINALIZAR ESTE ARTÍCULO

Bueno. Lo anterior ha sido una “pincelada” sobre el tema de los nombres. Deciros que existe
una página con propuestas sobre normalización según el sistema Leszynski de nombres que
podéis consultar aquí (o bajar en pdf aquí). Os lo pongo porque hay muchos programadores
que siguen este sistema.

De una manera u otra, y utilicéis el sistema que utilicéis, lo que debemos tener en cuenta,
desde mi humilde punto de vista, es que todo resulte lo más cómodo posible para nosotros
como administradores-programadores de la base de datos.

7
Visítame en http://bit.ly/NckAccess
Un saludo, y...

¡suerte!

8
Visítame en http://bit.ly/NckAccess