En términos de rendimiento, esto no sería un problema importante aquí.
La principal diferencia es que la función definida por el usuario se puede utilizar en la expresión de su código, donde no puede hacerlo un sub.
Esto es realmente un ENORME Monte Everest de una diferencia aquí.
Esta diferencia no está limitada a Access, sino que tiende a aplicarse a todos los lenguajes de programación y sistemas que se me ocurren que admiten la creación de funciones definidas por el usuario.
La ventaja clave de la utilización de función definida son muchas, pero el problema más fundamental es que tal función se puede utilizar en las expresiones.
Por ejemplo, al hacer clic en un botón de un formulario, generalmente puede tener una sola rutina VBA [Código de evento] asociada a ese botón.
Sin embargo se puede colocar también una expresión en la hoja de propiedades de esta manera:
=MyUserFunction()
Lo anterior es un consejo útil, ya que entonces se puede poner de relieve 10 controles en un formulario, y el tipo en la expresión anterior y usted acaba de asignar la función anterior a esos 10 botones. No puedes hacer lo anterior con un sub.
Otra diferencia significativa es que puede usar una función como una fuente de datos (expresión) para un cuadro de texto en un formulario o informe (de nuevo, no puede hacer esto con un sub).
Otra diferencia significativa es que puede utilizar estas funciones en SQL. Esta es una habilidad verdaderamente fantástica ya que puede tener el código "ejecutado" para cada fila de una consulta. Y esto significa que puede ampliar la capacidad y funcionalmente de SQL.
Y puede incluso utilizar esta idea para mostrar una variable VBA en una consulta SQL ya que simplemente crea una función pública que devuelve la variable VBA y puede utilizarse en una consulta; sin embargo, no puede usar variables VBA en una consulta !
Y esto se extiende de SQL abre un sinfín de ideas:
Por lo tanto, se puede construir una función pública llamada Mañana()
Public Function Tomorrow() as date
Tomorrow() = date() + 1
End Function.
Ahora en el generador de consultas, puedo ir:
Select FirstName, lastName, Tomorrow() as NextDay from tblCustomers
Y usted puede incluso hacer conversiones personalizadas tales como:
Select FirstName, LastName, Celsius([DailyGreenHouseTemp]) from tblGreenHouse.
La lectura diaria de la temperatura por encima pude en en grados Fahrenheit y sólo tiene que definir una función pública llamada Celsius así:
Public Function Celsius(Temperature As Variant) As Variant
Celsius = (Temperature * 1.8) + 32
End Function
Ahora bien, aunque la función de arriba es simple, que podría hacer registro complejo conjunto procesamiento de un complejo Algoritmo para determinar la humedad sobre una maceta en función de la temperatura y la humedad.
Así que una vez que definimos dicha función pública, entonces el concepto clave es que dicha función se puede usar no solo en el código VBA como expresión, sino que también se puede utilizar lo suficientemente increíble como SQL.
Así que incluso en el código, puede ir:
If MyCustomfucntion(SomeVar) = lngTestValue then
De nuevo en lo anterior, no se puede utilizar un sub en expresiones VBA.
Y aún más interesante es cuando se utiliza XML personalizado para cintas en Access, luego, si utiliza una expresión function() para el atributo "on action" entonces puede evitar la necesidad de volver a llamar a ribbon. Aún mejor es que la cinta llamará a esas funciones() en el formulario actual, no a un módulo de código público como DEBE hacer con las llamadas de cinta.
Probablemente podría escribir en otras 10 páginas en cuanto a la diferencia, pero creo que comenzaría a ser redundante y no quiero que parezca condensado de ninguna manera aquí.
Por lo tanto, la diferencia básica entre un sub y la función en VBA o, de hecho, en la mayoría de los lenguajes de programación es bastante similar.
Y los beneficios de usar una función en Access o casi cualquier lenguaje de programación también son muy similares. Por ejemplo, puedo definir una función definida por el usuario en t-sql (escalar), y de nuevo puede utilizar esa función t-sql en cualquiera de sus códigos t-sql o incluso desea que cree y use para el servidor sql.
Así que esta es la diferencia básica y simple entre un sub y una función, y me atrevo a decir que aquellos que han escrito código de computadora en casi cualquier lenguaje de programación se darán cuenta al instante de las diferencias importantes y útiles entre una subrutina y una función .
Una llamada de * subrutina * es una afirmación; una llamada de una función es una * expresión *. Las subrutinas son para situaciones en las que necesita hacer algo sin producir un valor de retorno. – dasblinkenlight
Todos, gracias por las respuestas, agradezco los puntos, sin embargo, lo que estoy tratando de hacer es, si necesito ejecutar una rutina que no devuelva un valor. ¿Un subtraductor traerá beneficios sobre una función, @TheNewOne ha resaltado que los tiempos de sub ejecución pueden ser mejores pero no se puede leer como una conclusión comprobada? –
Encontré una discusión en bytes.com que puede ser de interés. No estoy seguro de si juzgará la (muy leve) mejora del rendimiento con un Sub como una conclusión comprobada. Personalmente, utilizo un criterio simple: el procedimiento será un Sub a menos que lo necesite para devolver un valor con la asignación de tipo de datos AS de una función. http://bytes.com/topic/access/answers/209591-function-vs-sub-public-vs-private – HansUp