First Published 24 Sept 2023

This article discusses the purpose of the SysCmd (system command) action 555 available in Access.
This is currently unsupported/undocumented and many experienced Access developers may never have used it.

NOTE:
1.   Details of most of the supported SysCmd actions are documented at AcSysCmdAction enumeration (Access)
2.   For more information about all the supported actions and several of the unsupported SysCmd actions, see my recent article Unsupported SysCmd Actions



Using SysCmd(555)

The standard syntax for SysCmd actions is: SysCmd(Action, Argument2, Argument3) where the Action is required and the other 2 arguments are used in certain cases.

In the case of SysCmd (555), no additional arguments are required. To use it, you can just type SysCmd(555) in the immediate window and press Enter.

This will force the creation of two system tables, MSysIMEXSpecs and MSysIMEXColumns, if the tables don't already exist. These are used to store the details of saved import/export (IMEX) specifications.



Both of the MSysIMEX system tables shown above are automatically created when you first save an 'old-style' import/export text specification.


So why am I writing an article praising the merits of SysCmd(555) when the same result is achieved automatically?

The real value comes when you need to do this using automation in an external database.
For example, I recently used this action as part of my Database Analyzer Pro application.

This includes automation code to export database objects from the external database as text files.

For all objects except tables, I do this using SaveAsText (also undocumented!).

For tables, that method doesn’t work so I use TransferText with the syntax:
      appAcc.DoCmd.TransferText acExportDelim, , ObjName, strTarget, True
where appAcc is an Access automation object.

I had deliberately not specified an export specification for this purpose in my Analyzer application code as I (wrongly) believed it would then use the default specification for each user depending on their locale.

However, a user running Spanish language Office reported this code causing error 3441:
      Text file specification field separator matches decimal separator or text delimiter.

The problem was that the Spanish locale uses a comma as the decimal separator and this conflicted with using it as a field separator in the exporte text file.

My solution to this error is as follows:

•   Create an export specification using the pipe character "|" as the field separator – as far as I am aware, this is not used as a delimiter in any locale
•   Export that specification to the MSysIMEXSpecs table in the external database
•   Where that table doesn’t exist, I used appAcc.SysCmd 555 to create it (and the MSysIMEXColumns table)

User feedback indicates this solution works perfectly though I will continue to test in various different languages in case of other separator conflicts.


I have written this article partly as a belated thank you to whomever on the Access team first thought of creating SysCmd 555 20+ years ago.

THANK YOU SO MUCH. You have made my life so much easier on several occasions . . .



NOTE:
1.   The newer IMEX data tasks available in A2010 or later use a different approach based on XML and make no use of these system tables
      For more details of that approach, see my article: View & Edit Import/Export (IMEX) Data Task Specifications



2.   I recently submitted a formal request for the most useful of the undocumented SysCmd values that still work in current versions to be officially supported / documented.
      In particular, SysCmd values 504, 555 and 715.

      I have also asked that a new SysCmd value (e.g. 911) be created that will return the full Access version, build and bitness information.
      For example: Access 365 32-bit Version 2310 (Build 16907.20000 Click to Run) - Beta Channel

      All of this information (and more) can be obtained using my free Access/Windows Version Checker add-in for Access.


      However, at the moment, in order to get all this information using code, I have to use several VBA functions including WMI code, check multiple registry settings             and do a web scrape from an online Microsoft help article to get the YYMM version number! It works and is very fast but also extremely convoluted!

      NOTE:
      If you support these requests, PLEASE vote for them in the Access feedback portal:
           Please officially support these undocumented SysCmd actions
           Create a new SysCmd action to return the full Office version / build & bitness info



Feedback

Please use the contact form below to let me know whether you found this article interesting/useful or if you have any questions/comments.

Please also consider making a donation towards the costs of maintaining this website. Thank you



Colin Riddington           Mendip Data Systems                 Last Updated 24 Sept 2023

Return to Access Blog Page

Return to Top