Spotting inefficiencies in Microsoft Access projects

BrianW — Thu, 24 Mar 2011 14:09:14 +0000

Most businesses use Microsoft Office products as a cheap and simple solution to
    meet everyday business needs. Typically, what begins as a simple way to store
    and process data, becomes a time-consuming, error-prone process that is difficult
    to manage and maintain. Fortunately, we has extensive experience in
    automating, streamlining and extending these processes.

Businesses who fall into the above category generally don’t realize how powerful
    MS Access really is. They may use Excel to format data, import that data into Access
    and then use that data to update, query and report on. The following are almost standard
    practice in small and large businesses:

  • Use Excel to format data
  • Use multiple (manual) steps to maintain an excel spreadsheet
  • Use multiple (manual) steps to update an Access table
  • Combine data stored in multiple spreadsheets or tabs
  • Create reports manually
  • Create files (exported) manually
  • Get data from a database (sql)
  • Use multiple Access databases. (can typically use 1)

Pearl Technology has extensive experience with automation, streamlining and enhancing
these points. Examples:

  • Create data entry screens
  • Create forms to automate most manual processes
  • Create backup files/tables
  • Create log files to track changes
  • Link to external data, tables, files…
  • Validate input data
  • Set up auditing queries
  • Create reports
  • Create export queries (to excel, flat files..)

These are all good selling points for MS office product users.

Microsoft Excel cultural formatting

BrianW — Thu, 13 Jan 2011 19:19:49 +0000

I have worked extensively with Microsoft Office products for the past several years. Usually
working with MS Access, I’ve written hundreds of queries and countless lines of VBScript. I was
recently assigned the task of upgrading an Excel workbook from 2003 to 2007/2010. Simple, straight-forward
process, right? Well, for the most part, yes. After several days of cell – formula chasing I was
able to resolve all the listed issues and gave the product back to the client for testing. A few more changes
were needed but eventually the client was happy with the finished upgrades.
A few days later I received an email stating that the workbook would not work for one of the offices.
After looking back through code and testing different data, I was unable to reproduce any errors. I requested
a screen shot of the error message to at least have a starting point to resolve the issue. As I looked at the error message I realized they had left out one vital piece of information. The office was in Venezuela and the error message was in Spanish! After adjusting my local settings, I was now able to reproduce the error message.
The following code was responsible:
With ActiveSheet.ChartObjects(2).Chart.Axes(xlCategory)
    .MinimumScale = 0
    .MaximumScale = Range(”bigx”)
    .MinorUnitIsAuto = False
    bigx = Sheets(”calculations”).Range(”AJ14″)
    If bigx < 14 And big >= 0 Then
    .MajorUnit = (”1″)
    .MinorUnit = (”.5″)             ‘
    ElseIf bigx < 30 And bigx >= 14 Then
    .MajorUnit = (”2″)
    .MinorUnit = (”.5″)             ‘
    ElseIf bigx < 100 And bigx >= 30 Then
    .MajorUnit = (”5″)
    .MinorUnit = (”1″)
    .ScaleType = x1linear
    .DisplayUnit = x1none
    End If
End With

Now Excel is supposed to adjust for cultural differences based on the local settings of the
user and it does for most instances. It successfully adjusts for differences in numeric data
formatting. So why was this code causing an error? Because the data filling the major & minor
units was not numeric data. MinorUnit = (”.5″) in English equal to .MinorUnit = (”,5″) in
Spanish. Trapping the error and adding code to accommodate this situation was simple.
Problem solved. Client happy.

Pearl Tech » BrianW

Spotting inefficiencies in Microsoft Access projects

Microsoft Excel cultural formatting