Formato fecha dd.mm.aaaa y consultas de dominio (dmax, dsum, ...)

Discussion:

(demasiado antiguo para responder)

Uno +

2009-12-15 06:57:48 UTC

He observado que en consultas de dominio con criterios de fecha, si el
carácter separador de fecha en el formato establecido en Windows es el punto
(.) (por ejemplo 25.11.2009), las funciones de dominio (dsum...) devuelven
un error de sintáxis.

dim ltmp as long
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25.11.2009#")
Esto provoca un error de sintaxis
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25/11/2009#")
Esto va perfectamente.

¿Se os ocurre una idea para evitar este error sin cambiar el formato de
fecha en Windows? ¿Sabe alguien con seguridad si forzando el cambio mediante
código del carácter separador la función reconocerá perfectamente el formato
de fecha? En las pruebas que he hecho parece que sí.

Emilio

2009-12-15 14:35:21 UTC

Permalink

Post by Uno +
He observado que en consultas de dominio con criterios de fecha, si el
carácter separador de fecha en el formato establecido en Windows es el
punto (.) (por ejemplo 25.11.2009), las funciones de dominio (dsum...)
devuelven un error de sintáxis.
dim ltmp as long
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25.11.2009#")
Esto provoca un error de sintaxis
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25/11/2009#")
Esto va perfectamente.
¿Se os ocurre una idea para evitar este error sin cambiar el formato de
fecha en Windows? ¿Sabe alguien con seguridad si forzando el cambio
mediante código del carácter separador la función reconocerá perfectamente
el formato de fecha? En las pruebas que he hecho parece que sí.

Uno +

2009-12-15 15:23:08 UTC

Permalink

Hola Emilio.

Primero, gracias por tu respuesta.

No sé si esto debe entenderse como VBA o el problema es la función DMax.
Entiendo yo que DMax se puede evaluar directamente por Jet sin necesidad de
VBA... por eso no digo directamente que no tengas razón, pero empíricamente
no rula desde mi planteamiento como tu dices...

Me explicaré mejor con un ejemplo. Tomemos esta función:
Sub Prueba(stCri As String)
Debug.Print DMax("ID", "Compras", "Fecha < #" & (stCri) & "#")
End Sub

stCri será el parámetro a pasar: la fecha a evaluar. Ya ves que va como
string. Creo que no es necesario explicar los parámetros de DMax
Suponiendo que tengas una tabla llamada Compras que contenga los campos ID
(long integer) y Fecha (date) se evaluará correctamente si pasas como
parámetro cualquiera de estos valores
25/11/2009
25-11-2009
25 11 2009
25,11,2009
Como ves, en formato dd/mm/yyyy y utilizando como separadores incluso el
espacio o las comas. Cascaría, sin embargo, con 25.11.2009

Un saludo.

"Emilio" <miliuco56 ALGARROBA hotmail PUNTO com> escribió en el mensaje de

Post by Uno +
He observado que en consultas de dominio con criterios de fecha, si el
carácter separador de fecha en el formato establecido en Windows es el
punto (.) (por ejemplo 25.11.2009), las funciones de dominio (dsum...)
devuelven un error de sintáxis.
dim ltmp as long
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25.11.2009#")
Esto provoca un error de sintaxis
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25/11/2009#")
Esto va perfectamente.
¿Se os ocurre una idea para evitar este error sin cambiar el formato de
fecha en Windows? ¿Sabe alguien con seguridad si forzando el cambio
mediante código del carácter separador la función reconocerá
perfectamente el formato de fecha? En las pruebas que he hecho parece que
sí.

Emilio

2009-12-15 15:32:21 UTC

Permalink

Post by Uno +
Hola Emilio.
Primero, gracias por tu respuesta.
No sé si esto debe entenderse como VBA o el problema es la función DMax.
Entiendo yo que DMax se puede evaluar directamente por Jet sin necesidad
de VBA... por eso no digo directamente que no tengas razón, pero
empíricamente no rula desde mi planteamiento como tu dices...
Sub Prueba(stCri As String)
Debug.Print DMax("ID", "Compras", "Fecha < #" & (stCri) & "#")
End Sub
stCri será el parámetro a pasar: la fecha a evaluar. Ya ves que va como
string. Creo que no es necesario explicar los parámetros de DMax
Suponiendo que tengas una tabla llamada Compras que contenga los campos ID
(long integer) y Fecha (date) se evaluará correctamente si pasas como
parámetro cualquiera de estos valores
25/11/2009
25-11-2009
25 11 2009
25,11,2009
Como ves, en formato dd/mm/yyyy y utilizando como separadores incluso el
espacio o las comas. Cascaría, sin embargo, con 25.11.2009
Un saludo.
"Emilio" <miliuco56 ALGARROBA hotmail PUNTO com> escribió en el mensaje de

Post by Uno +
He observado que en consultas de dominio con criterios de fecha, si el
carácter separador de fecha en el formato establecido en Windows es el
punto (.) (por ejemplo 25.11.2009), las funciones de dominio (dsum...)
devuelven un error de sintáxis.
dim ltmp as long
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25.11.2009#")
Esto provoca un error de sintaxis
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25/11/2009#")
Esto va perfectamente.
¿Se os ocurre una idea para evitar este error sin cambiar el formato de
fecha en Windows? ¿Sabe alguien con seguridad si forzando el cambio
mediante código del carácter separador la función reconocerá
perfectamente el formato de fecha? En las pruebas que he hecho parece
que sí.

Emilio

2009-12-15 16:05:48 UTC

Permalink

--------------------------------------------------------------------------
¡Importante!: Colabora con el grupo.Contesta a este mensaje y dinos si te
sirvió o no la respuesta dada. Muchas gracias
--------------------------------------------------------------------------
Hola!
tal y como te decía en primer mensaje por norma debes utilizar formato
mmddyy, si utilizas ddmmy te arriesgas a que los datos devueltos para los
doce primeros días de mes sean incorrectos, así pues utiliza como norma

"Fecha < #" & format(stCri,"mm/dd/yy") & "#"

y te aseguro que nunca tendrás un problema, siempre y cuando no trabajes con
variables string para tratar fechas, en cuyo caso tendrás mas de un
disgusto.

Saludos a ***@s
Emilio [MS-MVP Access 2006/9]
miliuco56 ALGARROBA hotmail.com
http://www.mvp-access.com/foro
http://www.mvp-access.es/emilio

Post by Uno +
Hola Emilio.
Primero, gracias por tu respuesta.
No sé si esto debe entenderse como VBA o el problema es la función DMax.
Entiendo yo que DMax se puede evaluar directamente por Jet sin necesidad
de VBA... por eso no digo directamente que no tengas razón, pero
empíricamente no rula desde mi planteamiento como tu dices...
Sub Prueba(stCri As String)
Debug.Print DMax("ID", "Compras", "Fecha < #" & (stCri) & "#")
End Sub
stCri será el parámetro a pasar: la fecha a evaluar. Ya ves que va como
string. Creo que no es necesario explicar los parámetros de DMax
Suponiendo que tengas una tabla llamada Compras que contenga los campos
ID (long integer) y Fecha (date) se evaluará correctamente si pasas como
parámetro cualquiera de estos valores
25/11/2009
25-11-2009
25 11 2009
25,11,2009
Como ves, en formato dd/mm/yyyy y utilizando como separadores incluso el
espacio o las comas. Cascaría, sin embargo, con 25.11.2009
Un saludo.
"Emilio" <miliuco56 ALGARROBA hotmail PUNTO com> escribió en el mensaje

Post by Uno +
He observado que en consultas de dominio con criterios de fecha, si el
carácter separador de fecha en el formato establecido en Windows es el
punto (.) (por ejemplo 25.11.2009), las funciones de dominio (dsum...)
devuelven un error de sintáxis.
dim ltmp as long
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25.11.2009#")
Esto provoca un error de sintaxis
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25/11/2009#")
Esto va perfectamente.
¿Se os ocurre una idea para evitar este error sin cambiar el formato de
fecha en Windows? ¿Sabe alguien con seguridad si forzando el cambio
mediante código del carácter separador la función reconocerá
perfectamente el formato de fecha? En las pruebas que he hecho parece
que sí.

Uno +

2009-12-17 18:11:31 UTC

Permalink

Efectivamente Emilio.
Muchas gracias. La comprobación la hacía con fechas mayores de 12
precisamente para saber si era capaz el sistema de evaluar un día mayor y
evitar que lo confundiera con un mes. Vaya la que estaba preparando...
Resulta que, como bien apuntáis tanto Patxi como tú, si es mayor que 12 lo
interpreta como día (dd/mm/aaaa) y si es menor lo interpreta como mes
(mm/dd/aaaa)...

Así pues, definitivamente, las llamadas a funciones de dominio desde vba con
criterios de fecha quedarán así:
ltmp = DMax("CampoEnElQueMirar", "TablaX", "Fecha < #" & Format(stCri,
"MM/dd/yyyy") & "#")

Gracias nuevamente.

"Emilio" <miliuco56 ALGARROBA hotmail PUNTO com> escribió en el mensaje de

Post by Emilio
--------------------------------------------------------------------------
¡Importante!: Colabora con el grupo.Contesta a este mensaje y dinos si te
sirvió o no la respuesta dada. Muchas gracias
--------------------------------------------------------------------------
Hola!
tal y como te decía en primer mensaje por norma debes utilizar formato
mmddyy, si utilizas ddmmy te arriesgas a que los datos devueltos para los
doce primeros días de mes sean incorrectos, así pues utiliza como norma
"Fecha < #" & format(stCri,"mm/dd/yy") & "#"
y te aseguro que nunca tendrás un problema, siempre y cuando no trabajes
con variables string para tratar fechas, en cuyo caso tendrás mas de un
disgusto.
Emilio [MS-MVP Access 2006/9]
miliuco56 ALGARROBA hotmail.com
http://www.mvp-access.com/foro
http://www.mvp-access.es/emilio

Post by Uno +
Hola Emilio.
Primero, gracias por tu respuesta.
No sé si esto debe entenderse como VBA o el problema es la función DMax.
Entiendo yo que DMax se puede evaluar directamente por Jet sin necesidad
de VBA... por eso no digo directamente que no tengas razón, pero
empíricamente no rula desde mi planteamiento como tu dices...
Sub Prueba(stCri As String)
Debug.Print DMax("ID", "Compras", "Fecha < #" & (stCri) & "#")
End Sub
stCri será el parámetro a pasar: la fecha a evaluar. Ya ves que va como
string. Creo que no es necesario explicar los parámetros de DMax
Suponiendo que tengas una tabla llamada Compras que contenga los campos
ID (long integer) y Fecha (date) se evaluará correctamente si pasas como
parámetro cualquiera de estos valores
25/11/2009
25-11-2009
25 11 2009
25,11,2009
Como ves, en formato dd/mm/yyyy y utilizando como separadores incluso el
espacio o las comas. Cascaría, sin embargo, con 25.11.2009
Un saludo.
"Emilio" <miliuco56 ALGARROBA hotmail PUNTO com> escribió en el mensaje

Post by Uno +
He observado que en consultas de dominio con criterios de fecha, si el
carácter separador de fecha en el formato establecido en Windows es el
punto (.) (por ejemplo 25.11.2009), las funciones de dominio (dsum...)
devuelven un error de sintáxis.
dim ltmp as long
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25.11.2009#")
Esto provoca un error de sintaxis
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25/11/2009#")
Esto va perfectamente.
¿Se os ocurre una idea para evitar este error sin cambiar el formato
de fecha en Windows? ¿Sabe alguien con seguridad si forzando el cambio
mediante código del carácter separador la función reconocerá
perfectamente el formato de fecha? En las pruebas que he hecho parece
que sí.

Uno +

2009-12-17 18:09:47 UTC

Permalink

Efectivamente Emilio.
Muchas gracias. La comprobación la hacía con fechas mayores de 12
precisamente para saber si era capaz el sistema de evaluar un día mayor y
evitar que lo confundiera con un mes. Vaya la que estaba preparando...
Resulta que si es mayor que 12 lo interpreta como día (dd/mm/aaaa) y si es
menor lo interpreta como mes (mm/dd/aaaa)...

Así pues, definitivamente, las llamadas a funciones de dominio desde vba con
criterios de fecha quedarán así:
ltmp Max("CampoEnElQueMirar", "TablaX", "Fecha < #" & Format(stCri,
"MM/dd/yyyy") & "#")

Gracias nuevamente.

"Emilio" <miliuco56 ALGARROBA hotmail PUNTO com> escribió en el mensaje de

Post by Uno +
Hola Emilio.
Primero, gracias por tu respuesta.
No sé si esto debe entenderse como VBA o el problema es la función DMax.
Entiendo yo que DMax se puede evaluar directamente por Jet sin necesidad
de VBA... por eso no digo directamente que no tengas razón, pero
empíricamente no rula desde mi planteamiento como tu dices...
Sub Prueba(stCri As String)
Debug.Print DMax("ID", "Compras", "Fecha < #" & (stCri) & "#")
End Sub
stCri será el parámetro a pasar: la fecha a evaluar. Ya ves que va como
string. Creo que no es necesario explicar los parámetros de DMax
Suponiendo que tengas una tabla llamada Compras que contenga los campos
ID (long integer) y Fecha (date) se evaluará correctamente si pasas como
parámetro cualquiera de estos valores
25/11/2009
25-11-2009
25 11 2009
25,11,2009
Como ves, en formato dd/mm/yyyy y utilizando como separadores incluso el
espacio o las comas. Cascaría, sin embargo, con 25.11.2009
Un saludo.
"Emilio" <miliuco56 ALGARROBA hotmail PUNTO com> escribió en el mensaje

Post by Uno +
He observado que en consultas de dominio con criterios de fecha, si el
carácter separador de fecha en el formato establecido en Windows es el
punto (.) (por ejemplo 25.11.2009), las funciones de dominio (dsum...)
devuelven un error de sintáxis.
dim ltmp as long
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25.11.2009#")
Esto provoca un error de sintaxis
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25/11/2009#")
Esto va perfectamente.
¿Se os ocurre una idea para evitar este error sin cambiar el formato
de fecha en Windows? ¿Sabe alguien con seguridad si forzando el cambio
mediante código del carácter separador la función reconocerá
perfectamente el formato de fecha? En las pruebas que he hecho parece
que sí.

Emilio

2009-12-17 18:50:58 UTC

Permalink

:-))

Saludos a ***@s desde Huelva

Emilio [MS-MVP Access 2006/9]
miliuco56 ALGARROBA hotmail.com
http://www.mvp-access.com/foro
http://www.mvp-access.es/emilio

Post by Uno +
Efectivamente Emilio.
Muchas gracias. La comprobación la hacía con fechas mayores de 12
precisamente para saber si era capaz el sistema de evaluar un día mayor y
evitar que lo confundiera con un mes. Vaya la que estaba preparando...
Resulta que si es mayor que 12 lo interpreta como día (dd/mm/aaaa) y si es
menor lo interpreta como mes (mm/dd/aaaa)...
Así pues, definitivamente, las llamadas a funciones de dominio desde vba
ltmp Max("CampoEnElQueMirar", "TablaX", "Fecha < #" & Format(stCri,
"MM/dd/yyyy") & "#")
Gracias nuevamente.
"Emilio" <miliuco56 ALGARROBA hotmail PUNTO com> escribió en el mensaje de

Post by Uno +
Hola Emilio.
Primero, gracias por tu respuesta.
No sé si esto debe entenderse como VBA o el problema es la función
DMax. Entiendo yo que DMax se puede evaluar directamente por Jet sin
necesidad de VBA... por eso no digo directamente que no tengas razón,
pero empíricamente no rula desde mi planteamiento como tu dices...
Sub Prueba(stCri As String)
Debug.Print DMax("ID", "Compras", "Fecha < #" & (stCri) & "#")
End Sub
stCri será el parámetro a pasar: la fecha a evaluar. Ya ves que va como
string. Creo que no es necesario explicar los parámetros de DMax
Suponiendo que tengas una tabla llamada Compras que contenga los campos
ID (long integer) y Fecha (date) se evaluará correctamente si pasas
como parámetro cualquiera de estos valores
25/11/2009
25-11-2009
25 11 2009
25,11,2009
Como ves, en formato dd/mm/yyyy y utilizando como separadores incluso
el espacio o las comas. Cascaría, sin embargo, con 25.11.2009
Un saludo.
"Emilio" <miliuco56 ALGARROBA hotmail PUNTO com> escribió en el mensaje

Post by Uno +
He observado que en consultas de dominio con criterios de fecha, si
el carácter separador de fecha en el formato establecido en Windows
es el punto (.) (por ejemplo 25.11.2009), las funciones de dominio
(dsum...) devuelven un error de sintáxis.
dim ltmp as long
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25.11.2009#")
Esto provoca un error de sintaxis
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25/11/2009#")
Esto va perfectamente.
¿Se os ocurre una idea para evitar este error sin cambiar el formato
de fecha en Windows? ¿Sabe alguien con seguridad si forzando el
cambio mediante código del carácter separador la función reconocerá
perfectamente el formato de fecha? En las pruebas que he hecho parece
que sí.

Patxi Sanz

2009-12-15 15:50:49 UTC

Permalink

Como te ha dicho Emilio, tanto el VBA como el motor Jet esperan que se
indiquen los literales de fechas de una determinada forma. Y esa forma es la
siguiente:

1.- Delimitada por almohadillas.
2.- Formato anglosajón: mes/día/año

Cualquier otra cosa que uses, puede servir o no, dependiendo de lo que pueda
hacer el VBA o el Jet: si lo pueden convertir a una fecha que entiendan, lo
convertirán, y podrás encontrarte con resultados buenos o malos. Si no lo
pueden convertir, darán un error:

- En el caso del punto como separador, como no lo entienden, dan un error.

- Ahora estás pasando 25 de noviembre (25/11/2009). Espera que pases una
fecha como 5 de noviembre (5/11/2009), y verás que los resultados no son
correctos: VBA y Jet esperan el formato anglosajón, y entienden que esa
fecha es el 11 de mayo.

Si por las causas que sean, el usuario escribe una fecha usando el punto,
25.11.2009, y como ya sabes que vas a obtener un error, puedes hacer 2
cosas:

1.- Dejar que sea Access el que avise del error, y que el usuario se
acostumbre a usar otro carácter.
2.- Usar código para reemplazar los puntos por otro carácter como la barra
(/).

--
Un saludo,

Patxi Sanz
Tudela (NA)

Uno +

2009-12-17 18:11:03 UTC

Permalink

Efectivamente Patxi.
Muchas gracias. La comprobación la hacía con fechas mayores de 12
precisamente para saber si era capaz el sistema de evaluar un día mayor y
evitar que lo confundiera con un mes. Vaya la que estaba preparando...
Resulta que, como bien apuntáis tanto Emilio como tú, si es mayor que 12 lo
interpreta como día (dd/mm/aaaa) y si es menor lo interpreta como mes
(mm/dd/aaaa)...

Así pues, definitivamente, las llamadas a funciones de dominio desde vba con
criterios de fecha quedarán así:
ltmp = DMax("CampoEnElQueMirar", "TablaX", "Fecha < #" & Format(stCri,
"MM/dd/yyyy") & "#")

Gracias nuevamente.

"Patxi Sanz" <patxisanz[ARROBA]yahoo[PUNTO]es> escribió en el mensaje de

Post by Patxi Sanz
Como te ha dicho Emilio, tanto el VBA como el motor Jet esperan que se
indiquen los literales de fechas de una determinada forma. Y esa forma es
1.- Delimitada por almohadillas.
2.- Formato anglosajón: mes/día/año
Cualquier otra cosa que uses, puede servir o no, dependiendo de lo que
pueda hacer el VBA o el Jet: si lo pueden convertir a una fecha que
entiendan, lo convertirán, y podrás encontrarte con resultados buenos o
- En el caso del punto como separador, como no lo entienden, dan un error.
- Ahora estás pasando 25 de noviembre (25/11/2009). Espera que pases una
fecha como 5 de noviembre (5/11/2009), y verás que los resultados no son
correctos: VBA y Jet esperan el formato anglosajón, y entienden que esa
fecha es el 11 de mayo.
Si por las causas que sean, el usuario escribe una fecha usando el punto,
25.11.2009, y como ya sabes que vas a obtener un error, puedes hacer 2
1.- Dejar que sea Access el que avise del error, y que el usuario se
acostumbre a usar otro carácter.
2.- Usar código para reemplazar los puntos por otro carácter como la barra
(/).
--
Un saludo,
Patxi Sanz
Tudela (NA)

Patxi Sanz

2009-12-17 19:40:12 UTC

Permalink

:-)

--
Un saludo,

Patxi Sanz
Tudela (NA)

Ju@nK [MVP 2006/9]

2009-12-15 14:53:38 UTC

Permalink

Yo suelo utilizar el . para presentar los controles con campo fecha, pero no
se me ocurre meterla así en un criterio, si el problema es el caracter,
cambiaselo (en tiempo de ejecución) o metelo con otro caracter - , /
(cualquiera de ellos te valdrá)
--
--
**
Salu2/Regards
***@nK [MVP Access] 2006/09
[DCE2003 ***] + VSTO [DCE2005 **]
http://juank.mvps.org http://www.juank.es
Correos personales o preguntas particulares en mi grupo
http://groups.google.es/group/juank?hl=es
www.juank.tk
¿Que es un MVP?, entérate en http://mvp.support.microsoft.com
**

Uno +

2009-12-15 15:29:03 UTC

Permalink

Gracias ***@nK. Esto ya lo había pensado, pero es que no controlo exactamente
en qué puntos y con qué funciones tengo establecidos criterios de este tipo.
Tendría que revisar todo el código y es que actualmente está usando el
carácter separador establecido en el SO. Lo normal es que la gente use - ó
/, como bien dices, pero un cliente en concreto (fue por lo que detecté el
problema) tenía configurado el punto como carácter separador. No me gusta
forzar a que los clientes tengan que cambiar configuración del SO para que
corran mis programas y me fastidia también tener que revisar todo el código
para que analice la expresión y la cambie mediante alguna rutina...

Por otro lado, sé que existe solución, pero un poco como curiosidad, quise
plantearlo a la comunidad. Revisa la respuesta que dí a la respuesta de
Emilio.
Gracias por tu aportación.

Un saludo.

Post by ***@nK [MVP 2006/9]
Yo suelo utilizar el . para presentar los controles con campo fecha, pero
no se me ocurre meterla así en un criterio, si el problema es el caracter,
cambiaselo (en tiempo de ejecución) o metelo con otro caracter - , /
(cualquiera de ellos te valdrá)
--
--
**
Salu2/Regards
[DCE2003 ***] + VSTO [DCE2005 **]
http://juank.mvps.org http://www.juank.es
Correos personales o preguntas particulares en mi grupo
http://groups.google.es/group/juank?hl=es
www.juank.tk
¿Que es un MVP?, entérate en http://mvp.support.microsoft.com
**

Post by Uno +
He observado que en consultas de dominio con criterios de fecha, si el
carácter separador de fecha en el formato establecido en Windows es el
punto (.) (por ejemplo 25.11.2009), las funciones de dominio (dsum...)
devuelven un error de sintáxis.
dim ltmp as long
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25.11.2009#")
Esto provoca un error de sintaxis
ltmp= dmax ("CampoEnElQueMirar","TablaX","Fecha > #25/11/2009#")
Esto va perfectamente.
¿Se os ocurre una idea para evitar este error sin cambiar el formato de
fecha en Windows? ¿Sabe alguien con seguridad si forzando el cambio
mediante código del carácter separador la función reconocerá
perfectamente el formato de fecha? En las pruebas que he hecho parece que
sí.