Category Archives: MS Access General Information

MS Access – Who is Logged In?

Another common need for most database administrators & developers is to be able to see who is logged into a database. A very common solution to this in the past has been to use the Jet UserRoster, see:

I personally find much more useful to create a table to log the database usage by the users and have a form open in hidden mode at the database startup to populate the table in question. There is also the added benefit that this method permit much more detailed information, and historical review (not possible with the UserRoster). The historical data can be very useful when determining users that did not disconnect properly (which can lead to corruption) from the database. The extra information can also be useful when troubleshooting problems.

So how can you create this simple log tracking form? Very easily and here is how:

  1. First, we need to create a table to log the comings and goings within our database. Please note that you can add or remove the quantity (number of fields) you wish to keep track of. To do so you can use the following Data Definition Language (DDL) to create the corresponding MS Access table:
CREATE TABLE tbl_Db_UserTracking 
   (UTEntryID AUTOINCREMENT PRIMARY KEY,
   OSUserName VARCHAR(255) NOT NULL,
   ComputerName VARCHAR(255),
   ComputerIP VARCHAR(20),
   DbEntry datetime NOT NULL,
   DbExit datetime);
  1. Then we need to create a login tracking form which will get open at startup in a hidden mode (so the user never actually sees it). Below is one example of this form. Since the form is never actually visible, you need not waste any time formatting it or performing any special layout… A bare minimum is required.
  2. Then we need to setup a method to automatically launch the form at startup. Since all of my databases use an AutoExec macro to perform a number of steps (relink the table, check user permissions, stratup logoff forms, …) at starup it is only logical to merely add this to the function that the AutoExec macro calls.
  3. Then we need to create a form for the administrator to use to review the data.

Disclaimer/Notes:

If you do not have Microsoft Access, simply download and install the freely available runtime version (this permits running MS Access databases, but not modifying their design):

Microsoft Access 2010 Runtime
Microsoft Access 2013 Runtime
Microsoft Access 2016 Runtime
Microsoft 365 Access Runtime

All code samples, download samples, links, ... on this site are provided 'AS IS'.

In no event will Devhut.net or CARDA Consultants Inc. be liable to the client/end-user or any third party for any damages, including any lost profits, lost savings or other incidental, consequential or special damages arising out of the operation of or inability to operate the software which CARDA Consultants Inc. has provided, even if CARDA Consultants Inc. has been advised of the possibility of such damages.

Download a Demo Database

Feel free to download a 100% unlocked demo copy by using the link provided below:

Download “Access - Who's Logged In (x32 accdb)” WhosLoggedIn_V1.000.zip – Downloaded 52196 times – 33.27 KB

Version History

V1.000 (2018-10-18)

MS Access – Deploying an Access Database using CITRIX

This is a preliminary posting on the subject, one that I hope to add to over time.

We see many postings on various forums from people wanting to know more about running an Access database via CITRIX.

Firstly, since Access is not recommended to be used over a wireless connection, nor a WAN, CITRIX is a very interesting solution to giving access to such databases.  That said, like everything in life, there are both pros and cons to such a deployment of your database.

Like with every MS Access database, to deploy it, you must first split the database into 2 components: front-end and back-end and then issue a copy of the front-end to each of your users.  This can easily be done in CITRIX.

Typically, in an effort to minimize the impact of internal networks…, I like to try and have the back-end installed directly on the CITRIX server itself.  By doing so, the database runs completely on the CITRIX server and there is no network impact, and the database also doesn’t take up valuable network bandwidth uselessly.  Of course, as with any installation, a reliable backup system must be put in place and validated on a regular basis.

As a developer, I always need to be given an administrative console with the full version of Access installed so I can perform tests, and more importantly compile my application locally to ensure proper compatibility.

Where I have seen issue occur…  Well, there can be a number of issues, but 2 specific issues seem to keep coming up recently.

  1. Insufficient Server capacity – Since the CITRIX server is an application server, it is crucial to ensure sufficient RAM, CPU power,….  I recently had to identify the fact that the CITRIX server was maxing the CPU and thus the database application I designed was miserably slow.  The IT department stated that the server was adequate so I added some custom code to log RAM and CPU usage to profile the server since they would not do so.  I was able to clearly demonstrate that the CPU was saturated.  Once they unloaded a few other applications from the server, all of a sudden my databases were running fine.  The funny thing was that the database was throwing network error, nothing relating to CPU, or anything remotely leading one to believe it was a resource problem.  Even more of a reason why the IT department was unwilling to believe my initial questions regarding their server.  All of this to say, once you set up your db, ask the IT dept to profile the server CPU, RAM, Network just to ensure everything is optimal.  it is so simple for them to do and can truly avoid weeks of headaches (for everyone).  This is also something that could be checked from time to time.
  2. Outdated/different server installations – Like any computer, the local setup can have an impact on application running on it.  You can develop a superb database application and once deployed on the server it may not work.  Why, simple because of a conflict caused by updates, difference in dll, exe, …    This is why in my opinion (and some people argue this point) that the CITRIX server be kept up to date both its OS and Access/Office installation.  Furthermore, it is crucial to compile your database on the local CITRIX server to ensure everything is proper.

That said, I must say that once things are setup properly, CITRIX can be very reliable and a very useful tool.

 

MS Access – Where to Start Learning – Database Tutorials

I always find it amazing that even with the internet, it can sometimes be very hard to sift through all the available materials to find good tutorials and learning tools. Below are a few good starting points. Some are MS Access specific, but many are just database generalities whose techniques can be used with any RDMS. So if you are starting off, or merely brushing up, here are a few good links to consider:

For starters, some of the best websites are those created by the various Microsoft Access MVPs.  I have compiled a separate list of their websites in the following post: https://www.devhut.net/mvp-sites/.

Continue reading

MS Access – Persistent Connection in a Split Database

 

The Art of Database Development: Establishing a Persistent Connection

When it comes to database development, seasoned professionals understand that best practices dictate a clear separation between two essential components: the Back-End, where your data resides, and the Front-End, which encompasses all the interactive elements like queries, forms, reports, macros, and modules. However, one crucial aspect that many developers overlook is the significance of maintaining a persistent connection between the Front-End and Back-End.
 
Continue reading

Windows Update KB2596856 / MS12-060 Breaks Microsoft Windows Common Control Library (MSCOMCTL.OCX)

On Tuesday, August 14, 2012, MS released a new update which in fact crippled any application which used the Microsoft Windows Common Control Library (MSCOMCTL.OCX)!  So anyone using any of the following Microsoft Windows Common Controls:

  •  Animation control
  • Button
  • Combo box
  • ComboBoxEx control
  • Date and time picker
  • Edit control
  • Flat scroll bar
  • Header control
  • Hot key control
  • Image list
  • IP address control
  • List box
  • List-view control
  • Month calendar control
  • Pager control
  • Progress bar
  • Property sheet
  • Rebar control
  • Rich edit control
  • Scroll bar
  • Static control
  • Status bar
  • SysLink control
  • Tab control
  • Task dialog
  • Toolbar
  • Tooltip
  • Trackbar
  • Tree-view control
  • Up-down control 

There have been numerous disccusions on the matter, amongst them:

And numerous proposed solutions, amongst them:

That said, the true solution, which partially worked for me (it resolved my computer’s problem and got me back up and running but a serious compatibility issue with all my clients still remains!  See below for more information) was finally release by MS (after the community had already done all the leg worked an figured it out on our own) and was posted at: MS12-060: Description of the security update for Office 2010: August 14, 2012.

All of this is very nice, but there remain 2 major issues:

  1. This solution relies on the end-user doing all the fixing, on every computer!  Why has MS not released a hot fix that would automatically have fixed this?!  MS screwed-ed big time and sadly has passed the puck on to everyone else, rather than addressing the issue.
  2. Furthermore, even if you fix your computer, your application will no longer work on any computer that hasn’t had this update applied!!!  Just a little problem if you ask me!  So in fact their solution does not truly resolve the problem entirely as their remains a major compatibility issue at the end of the day.

 

MS Access, WANs, Wireless Networks and the Internet

A common question, and increasingly so, is relating to using MS Access over WANs (Wide Area Networks – which the Internet qualifies as).

The short answer:  Keeping in mind the fact that MS Access uses the Jet/Ace database engine, MS Access simply does not, should not be used in any manner over WANs, wireless networks and/or the Internet.

The longer answer:  As with most things in life, there are always ways to bend the rules…  As such, there are techniques that permit one to use a database over WANs: the use of Terminal services, CITRIX, which the newer version of MS Access (2010 especially) developing your database as a Web database and publishing it to Office365.com, utilizing SharePoint services.  Albert Kallal, an MS Access MVP, has a very detailed post about MS Access and WANs which covers much more in detail the subject, especially the technical reasons: http://www.kallal.ca/Wan/Wans.html.

That all said, even though there are certain work arounds (each having their own set of pros and cons), I always ask my clients the same basic question: “What is the purpose of the database you are creating?”.  If it is an internal business tools (used over a wired LAN network), then MS Access is definitely worth exploring further.  If on the other hand, it is to be shared, over the Internet or corporate WAN, with lots of users/clients, etc.  then it is time to look at web databases (which Access simply is not – at least not in the standard sense of the term).  This is when you have to truly start looking into databases such as: MySQL (very common and cheap hosting is easy to find), PostgreSQL, SQL Server (harder to find host and more costly typically) and development languages such as: PHP, .Net, JAVA, and a multitude of others.

In summary:
In-house application used over a wired LAN connection-> MS Access is the apex in development tools!  It is the fastest and probably easiest development tool used by millions, upon millions of users around the world!!!
An application to be run over a WAN, Wireless Network and/or the Internet -> Turn to more professional web application and development tools.

VBA- Determine Executable Path for Given Application

Have you been trying to develop a flexible method of determining the path to launch an application. You quickly learn that software developers, in some instances, make it indredibly difficult for us to create a simple static path for the executable directory.

For instance, say you create a database and then deploy it, you can’t just use a static path to launch it, like:

C:\Program Files\Microsoft Office\OFFICE 11\MSACCESS.EXE

because this will work only with Office 2003. What happens if your user is using 2007, 2010, 2000, …???

So what can one do? Well, it is possible to create a series of if statements, to check and see if a 2010 folder exists, if not, then check for 2007, and so on, but this once again rellies on a series of static enties that you make as a developer. For typical installation this would work, but what about that special user that didn’t install Office in the typical location? Your script will fail, no and if or about it!

So What Can One Do?! Actually, the solution is quite straight foward and works for most every program. All we need to do is check with the registry as to where the program was installed/configured! That’s right, let’s just ask the computer, “where did you put the application”? The beauty is in its simplicity.

For MS access, we only need to do the following

Dim WSHShell
Set WSHShell = CreateObject("WScript.Shell")
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MSACCESS.EXE\")

Obviously, instead of sending the result to a msgbox we could assign it to a variable and use it to actually launch a database.

What other programs can we use this technique with? You name it: Excel, Groove, Internet Explorer, FireFox, Info Path, MS Access, One Note, Outlook, Power Point, Word, … and the list goes on. Below is but a few examples of other programs.

Dim WSHShell
Set WSHShell = CreateObject("WScript.Shell")
'MS Excel
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe\")
'Groove
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\GROOVE.EXE\")
'Internet Explore
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\IEXPLORE.EXE\")
'Info Path
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\infopath.exe\")
'MS Access
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MSACCESS.EXE\")
'MS One Note
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\OneNote.exe\")
'MS Outlook
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE\")
'PowerPoint
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\powerpnt.exe\")
'MS Word
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Winword.exe\")
'WordPad
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WORDPAD.EXE\")
'Write
MsgBox WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WRITE.EXE\")

So you can simply test out other application by using the appropriate executable or use regedit navigate to the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths” key and review the list of application present on your system.

But as you can see, with but 3 little lines, we can have a flexible way to get the path to our executable. No more guessing, no more messing!

Looking for a way to do the same thing in a bat file?!

Don’t worry, you can do the same thing using a bat file, below is an example

@echo off
REM Great reference on REG QUERY
REM 	https://www.robvanderwoude.com/regsearch.php
REM 	OR run reg query /? in a cmd window

set APPEXE=MSACCESS.EXE
set KEY_NAME=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
set FULL_KEY="%KEY_NAME%%APPEXE%"

FOR /F "skip=2 tokens=2,*" %%A IN ('REG QUERY %FULL_KEY% /ve') DO set "exePath=%%B"
ECHO %exePath%

MS Access – Decompile a Database

Decompiling an Access Database

As a developer, it becomes necessary to decompile your database from time to time.  The frequency depends on a multitude of factors, but at the very least, one should decompile one’s application prior to release.  Decompilation is yet one more step a develpper has to take to ensure their database/code is clean and optimal for their end-users.  Also, keep in mind that the best approach is to decompile the database on the development machine and then recompile on the end-user machine.  This ensures that the database is compiled using the end-user’s libraries minimizing any surprises when put into production.

Before going any further on this subject, let me emphasize once more the importance of making a backup of your database prior to performing a decompile of your database!

 

One-time Decompile

The MSACCESS.EXE command line accepts several command line switches, one of which is to allow decompiling your database.  There is no other means to decompile a database.  So one merely needs to create a shortcut including the appropriate command line switch in order to decompile any given database.  The basic syntax would be:

"FullPath\MSACCESS.EXE" "FullPathAndDbNameWithExtension" /decompile

Examples:

"C:\Program Files\Microsoft Office\Office\MSACESS.EXE" "C:\Databases\Test\Database1.mdb" /decompile

Or

"C:\Program Files (x86)\Microsoft Office\Office12\MSACESS.EXE" "C:\Databases\Test\Database1.mdb" /decompile

 

Reusable decompilation method

On the other hand, it become tedious to create a shortcut for each database you create/manage and as such a more automated method may be a good idea to implement.

  1. Using Windows Explorer (etc.) navigate your way to your MSACCESS.EXE and the copy the file.
  2. Navigate to the %APPDATA%\ Microsoft\Windows\SendTo\ Folder
  3.  Right-Click within the folder and select Paste shortcut from the context menu
  4. Rename the shortcut as you wish, for instance MSACCESS Decompile
  5. Right-Click on the newly created shortcut and select Properties from the context menu
  6. On the Shortcut tab, edit the Target control by adding /decompile to the existing value.
    You should end up with something along the lines of:
"C:\Program Files (x86)\Microsoft Office\Office12\MSACCESS.EXE" /decompile

Or

"C:\Program Files\Microsoft Office\Office12\MSACCESS.EXE" /decompile
  1. Click Ok
  2. Close windows explorer.

Now whenever you wish to decompile a database you need only right-click on the Access database in Windows Explorer and select “Send To –> MSACCESS Decompile.

 

Special Note

Since after decompiling we always perform a compact of the database, you can perform both in one step if you’d like by appending a /compact to your /decompile command.  This is not obligatory by any means.  Personally, I prefer the granularity of performing each step myself, but should you wish to automate things a little more you’d do something along the lines of:

"C:\Program Files\Microsoft Office\Office\MSACESS.EXE" "C:\Databases\Test\Database1.mdb" /decompile /compact

Or

"C:\Program Files (x86)\Microsoft Office\Office12\MSACESS.EXE" "C:\Databases\Test\Database1.mdb" /decompile /compact
"C:\Program Files (x86)\Microsoft Office\Office12\MSACCESS.EXE" /decompile /compact

Or

"C:\Program Files\Microsoft Office\Office12\MSACCESS.EXE" /decompile /compact

Do note that if you do implement this variation for the reusable decompilation method, you’d probably be best to also change the name attributed to the command in step 4. to MS Access Decompile and Compact

 

Proper Steps to Follow when Decompiling an Access Database

I found the following instructions from David Fenton, and thought they fit right into this subject.

  1. Backup your database.
  2. Compact your database.
  3. Decompile your database (per either method listed above. Be sure to bypass any startup code by holding down the shift key, so the code does not immediately recompile).
  4. Close that instance of Access.
  5. Open a new instance of Access and open the database you just decompiled, but BE SURE YOU BYPASS ALL STARTUP CODE (i.e., hold down the shift key). If you don’t do that, then you might as well go back to step 3 and try again, since if the startup code runs, your code will recompile before you are ready to do so.
  6. Compact the decompiled database (and be sure you hold down the shift key so that it bypasses the startup code; see #5).
  7. Open the VBE and on the Debug menu, choose COMPILE [name of project].
  8. On the file menu, save the project.
  9. Compact again.

Why are all these steps necessary?

Because you want to not just decompile the VBA, you want to make sure that all the data pages where the compiled p-code was stored are completely discarded before you recompile.

I also recommend:

  1. In the VBE options, turn off COMPILE ON DEMAND
  2. In the VBE, add the COMPILE button to your Toolbar.
  3. Compile often with that button on the toolbar, after every two or three lines of code.

Another good resource on the subject is Michael Kaplan’s article on the subject.

Lastly, instead of creating various shortcut to perform these actions, you may prefer to use my utility that will add such functionalities directly into the Windows Context Menu. To learn more check out Windows Explorer MS Access Database Right-Click Context Menu.

MS Access – Button Picture – doesn’t support this format … or the file size is too big

I came across the following post and wanted to see what the issue was since I routinely use Irfanview myself (it is a great, free no strings attached piece of software).

So I contacted the creator of Irfanview directly regarding the error, and he was able to pinpoint the exact nature of the problem.  As it turns out, the ico files created by Irfanview are just fine.  The issue is that MS Access would seem to expect a specific type of ico file (and doesn’t tell anyone this).

Irfanview creates a 24BPP (with no alpha layer) ico file while MS Access seems (based on my testing and returned information from Irfan) to expect a 32BPP with an alpha layer ico file.

So for anyone else ever seeing this this of error.  An ico is not an ico in the world of MS Access.  It is picky and requires a specific type of ico file.  So just be sure of the type of file your are creating is a 32BPP with an alpha layer ico and you should have no problems using them as a picture for a button.  Alternately, instead of having such issues using a ico file, use BMPs instead.  I personally don’t like BMPs as they aren’t used in any other programming (always jpg, gif, png, ico) so I will stay with ico so I can reuse them easily where I please.  It would be nice if MS would integrate common image files into the application, but that is out of my hands (if it were up to me many issues like this would have been resolve a long time ago!).

Hopefully this will help someone out.

MS Access 2007-2010 Ribbon Development

MS Access Ribbon - Home Tab

 

A while back, ok several years ago, I took a look at the new (at the time it was new) ribbon.  I was interested in porting my Custom Toolbars into the new and improved format.  At the time I spent hours trying to digg up information on the subject.

To put things bluntly, MS messed up good on the implementation!

This is not to say that the ribbon is not a powerful tool and all the rest of that.

That said, it has been implemented in what I consider an incomplete form.  MS provides no tool, to develop custom ribbons, no built-in callback routines…, no access to the ribbon built-in images, and so many more flaws I don’t even know where to start!  It is a mess.

Then they still support old custom toolbars, but you have no way to edit, delete or work with them directly.  You have to revert back to using 2003 or prior, or develop your VBA own code to interact with them.

The whole situation smells bad.

So what is one to do.  First off, you have to realize, that the entire Office suite Ribbon is fully customizable and to work with it you can use a Custom UI Editor, EXCEPT for MS Access.  That’s right, as usual, MS Access is in a category of its’ own.  What a surprise!

Firstly, get ready to do a lot of reading, before you are even ready to tackle creating a ribbon.  Here are a few places to start:

www.accessribbon.de
http://www.andypope.info/vba/ribboneditor.htm
http://msdn.microsoft.com/en-us/library/aa338202(v=office.12).aspx
http://msdn.microsoft.com/en-us/library/bb187398.aspx
http://www.rondebruin.nl/ribbon.htm

For MS Access, try http://www.ribboncreator.de/en/  The ribbon creator is a graphical interface to create the required XML and VBA code.  Basically, what MicroSoft forgot to include in its’ own software!!!  At the very least it will speed up development and you can tweak what it generates.

All in all, the ribbon, because of the way MS has chosen to implement a half baked technology, is a miserable failure (from the developer’s perspective)!  Actually, even from the end-user’s perspective also.  Where I used to be able to load 6 toolbars containing 50 icons (or more) where I had all the commands I needed at my finger tips, I now have 1 ribbon containing 10-20 commands.  You end up spending your time flipping back and forth, all day, between tabs!  It is never ending and tedious after a while.  This is MS’ idea of empowering the end-user?  Come on!  But hey, it looks cool dude!  This is the best that the best minds at MS could come up with; seriously!!!

That said, I believe MS has other plans for the ribbon, probably a way to introduce the end-user to the new layout, flow to be expected in future releases of their OS or other programs.  Let use not forget the fact that MS is playing a major game of catchup with MAC.