New SysCmd Actions That Give You Office Version Information From VBA

Microsoft just added a set of new SysCmd options in the Beta Channel. These give you clear and structured version details right from VBA. This makes diagnostics, logging, and support much easier.

Let’s walk through what is new.
 

Full Version String in One Call

 Debug.Print SysCmd(acSysCmdGetFullVersion) '720

Example output:

 Microsoft Access (Version 2603) Build 16.0.19920.20000 Beta Channel 64-bit 

This is useful when you need a quick snapshot of the environment. It includes version, build, channel, and bitness in one line.
 

Get Individual Version Details

If you need more control, you can pull each part separately.

Debug.Print SysCmd(acSysCmdGetVersion)         ' YYMM version - 721
Debug.Print SysCmd(acSysCmdGetFullBuildNumber) ' Full build string - 722
Debug.Print SysCmd(acSysCmdGetChannelName)     ' Update channel - 723
Debug.Print SysCmd(acSysCmdGetBitness)         ' 32-bit or 64-bit - 724
Debug.Print SysCmd(acSysCmdGetBuildNumber)     ' Access build number - 725

This is ideal for logging or conditional logic. For example, you can check the channel before enabling a feature, or log the exact build during error handling.
 

New Constant for MSO Build Number

The previously hidden SysCmd(715) now has a proper name:

Debug.Print SysCmd(acSysCmdGetMsoBuildNumber)      ' MSO major build number (Long) - 715

This returns the MSO DLL build number.
 

Important Differences

There are now three related build values. It is important to understand how they differ:

  • MSO Build Number (715)
    This comes from the shared Office components.
  • Access Build Number (725)
    This is specific to Microsoft Access.
  • Full Build Number (722)
    This is the full version string, for example
    16.0.19920.20000

These values may not always match. That is expected. Access and Office components can be updated on slightly different tracks.
 

IntelliSense and Runtime Support

All of these constants now appear in VBA IntelliSense. That makes them easier to discover and use.

They also work in Access Runtime. This is a big win for deployed applications where you still need environment insight.
 

No More Registry Checks

Although this announcement is far from revolutionary, as several of us had over the years provided the means to gather this information by simply reading the registry (a have a couple post on the subject here) and performing conversions of data, now you have clean, built-in and reliable access to:

  • Version number
  • Build details
  • Update channel
  • Bitness

Making error reporting/logging a little easier and avoiding having to get the user to collect such information themselves manually.

I still remain amazed how it took Microsoft over 10+ years to provide this simple functionality to developer and wonder why it was not part of the initial MS365 release as it has always been critical information needed to provide support to end users.
 

Final Thoughts

These additions are simple but useful. They remove friction and give developers better visibility into the Access environment.

They are still undocumented for now, but official documentation is expected soon. In the meantime, they are stable, discoverable, and ready to use in the BETA channel.

If you build or support Access apps, this is worth adding to your toolkit.

As of the date of publication, the Microsoft Access Dev Team has not posted anything regarding this on their blog, nor was it ever posted on the Roadmap.
 


 
Version française

Nouvelles actions SysCmd qui vous donnent les informations de version Office depuis VBA

Microsoft vient d’ajouter un ensemble de nouvelles options SysCmd dans le canal Beta. Elles vous donnent des détails de version clairs et structurés directement depuis VBA. Cela rend le diagnostic, la journalisation et le support beaucoup plus simples.

Voyons ce qui est nouveau.
 

Chaîne de version complète en un seul appel

 Debug.Print SysCmd(acSysCmdGetFullVersion) '720

Exemple de sortie :

 Microsoft Access (Version 2603) Build 16.0.19920.20000 Beta Channel 64-bit 

C’est utile quand vous avez besoin d’un aperçu rapide de l’environnement. Cela inclut la version, le build, le canal et le bitness sur une seule ligne.
 

Obtenir les détails de version individuellement

Si vous avez besoin de plus de contrôle, vous pouvez récupérer chaque élément séparément.

Debug.Print SysCmd(acSysCmdGetVersion) ' version YYMM - 721
Debug.Print SysCmd(acSysCmdGetFullBuildNumber) ' chaîne complète du build - 722
Debug.Print SysCmd(acSysCmdGetChannelName) ' canal de mise à jour - 723
Debug.Print SysCmd(acSysCmdGetBitness) ' 32-bit ou 64-bit - 724
Debug.Print SysCmd(acSysCmdGetBuildNumber) ' numéro de build Access - 725

C’est idéal pour la journalisation ou la logique conditionnelle. Par exemple, vous pouvez vérifier le canal avant d’activer une fonctionnalité, ou enregistrer le build exact lors de la gestion des erreurs.
 

Nouvelle constante pour le numéro de build MSO

Le SysCmd(715) auparavant caché a maintenant un nom officiel :

Debug.Print SysCmd(acSysCmdGetMsoBuildNumber) ' numéro de build principal MSO (Long) - 715

Cela retourne le numéro de build de la DLL MSO.
 

Différences importantes

Il existe maintenant trois valeurs de build liées. Il est important de comprendre leurs différences :

  • Numéro de build MSO (715)
    Cela provient des composants Office partagés.
  • Numéro de build Access (725)
    Cela est spécifique à Microsoft Access.
  • Numéro de build complet (722)
    C’est la chaîne complète de version, par exemple
    16.0.19920.20000

Ces valeurs ne correspondent pas toujours. C’est normal. Access et les composants Office peuvent être mis à jour à des rythmes légèrement différents.
 

Support IntelliSense et Runtime

Toutes ces constantes apparaissent maintenant dans IntelliSense VBA. Cela les rend plus faciles à découvrir et à utiliser.

Elles fonctionnent aussi dans Access Runtime. C’est un gros avantage pour les applications déployées où vous avez encore besoin d’informations sur l’environnement.
 

Fini les vérifications du registre

Même si cette annonce est loin d’être révolutionnaire, puisque plusieurs d’entre nous avions déjà, au fil des années, fourni des moyens de récupérer ces informations en lisant simplement le registre et en convertissant les données, vous avez maintenant un accès propre, intégré et fiable à :

  • Numéro de version
  • Détails du build
  • Canal de mise à jour
  • Bitness

Cela rend la journalisation et le rapport d’erreurs un peu plus simples et évite de demander à l’utilisateur de recueillir ces informations manuellement.

Je reste tout de même surpris que Microsoft ait mis plus de 10 ans à offrir cette fonctionnalité simple aux développeurs, et je me demande pourquoi elle ne faisait pas partie de la version initiale de MS365, puisqu’il s’agit d’informations essentielles pour offrir du support aux utilisateurs.
 

Mots de la fin

Ces ajouts sont simples mais utiles. Ils réduisent la friction et donnent aux développeurs une meilleure visibilité sur l’environnement Access.

Ils sont encore non documentés pour l’instant, mais une documentation officielle est attendue bientôt. En attendant, ils sont stables, faciles à découvrir et prêts à être utilisés dans le canal Beta.

Si vous développez ou supportez des applications Access, cela vaut la peine de les ajouter à votre boîte à outils.

À la date de publication, l’équipe de développement Microsoft Access n’a rien publié à ce sujet sur son blogue et cela n’a jamais été mentionné dans la feuille de route.