Aug 01

Total Access Statistics Ships for Microsoft Access 2013

Total Access StatisticsTotal Access Statistics is the most advanced data analysis program for Microsoft Access. It extends the power of Microsoft Access queries with a wide range of statistical calculations including percentiles, frequency distributions, correlations, regressions, rankings, running totals, financial cash flow analysis, data normalization, crosstabs with Chi-Square, t-Tests, ANOVA, non-parametrics, probabilities, and more.

Total Access Statistics is now available for Microsoft Access 2013. Total Access Statistics 2013 includes many enhancements since the prior release of Total Access Statistics 2010:

  • Support for the 32 and 64 bit versions of Access 2013 with separate add-ins for each
  • New redistributable runtime libraries to support Access 2013, 2010, 2007, and 2003
  • Support for Windows 8 (and all Windows versions supported by Access)
  • Improved performance when analyzing large data sets
  • For Percentiles, when assigning percentile values to a field in your table, you can specify calculations such as quartiles, quintiles, octiles, deciles, etc. rather than just percentile
  • Field format is set to Percent for percentage fields in the Frequency, Crosstab (when percentages are in columns), and Chi-Square details tables
  • When tables are generated from the add-in, the field column widths are resized to show the entire field name and data
  • Updated user manual and help file

Here’s a complete list of new features. For more information visit these resources:

Jul 10

Microsoft Access Class Not Registered Run-time Error -2147221164 (80040154)

Microsoft Access Triggers a Runtime Error ‘-2147221164 (80040154)': Class Not Registered

This error occurs in a Microsoft Access database that seems to work fine on every other machine but one. The MS Access database actually loads and runs, so the code is compiled and functional. Then it dies on some very common code such as CurrentProject.Connection for ADO to open a table or query recordset:

Microsoft Access "Class Not Registered" Run-time Error -2147221164 (80040154)

Confusion

The “Class Not Registered” is very confusing. It implies code that won’t compile or broken library references but that’s not the true cause. Is the Access database corrupt? No.

We’ve received reports for this error for years and were never able to reproduce it. We finally did and figured out why it occurs and how to fix it. Read our new paper Microsoft Access “Class Not Registered” Run-time Error ‘-2147221164 (80040154) to learn more.

Apr 14

Microsoft Access Videos from the SharePoint Conference

Microsoft Access ProductsMicrosoft SharePointThe Microsoft Access team has released videos of their presentations at the SharePoint Conference from Las Vegas, NV.

With Access 2013, Access web solutions are hosted in SharePoint and rather than using SharePoint lists as they did in Access 2010, they use a real SQL Server database hosted in SQL Azure. The database can also be linked from desktop copies of Access to create hybrid solutions that serve both the web and Windows.

The Microsoft Access program managers presented these four sessions:

Enjoy!

Other Videos from FMS

Mar 22

Total Visual Agent Ships for Microsoft Access 2013 and 2010

Microsoft Access Database SchedulerTotal Visual Agent for Microsoft Access DatabasesAutomate Microsoft Access Database Compact and Other Chores

We are very pleased to announce that Total Visual Agent 2013 is now shipping.

Don’t Forget System Administration for Microsoft Access Database Solutions

A professional Microsoft Access database application needs ongoing system administration. It’s an area that many MS Access developers neglect and causes problems when things go wrong (database corruption, missing backups, disaster recovery, etc.):

Enterprise Quality System Administration with Audit Logs and Email Alerts

Total Visual Agent has provided an Enterprise Quality solution for almost 20 years by giving organizations a reliable way to perform their critical tasks on a 24/7, 365 days a year basis. A detailed audit log documents each action that is performed, and sends emails if errors are encountered.

Schedule Events, Databases, and Actions to Perform

Total Visual Agent automates and schedules Microsoft Access tasks. It ensures repetitive tasks are completed reliably. Tasks such as database compact and repair, zipped backups, rolling backups (e.g. 7 copies for each day of the week), running macros, running Windows command lines, making copies of table data, collecting database statistics such as size and record counts, etc. Easily schedule tasks for the middle of the night and know they’ll be completed.

Events can be scheduled every X minutes, hourly, daily, weekly, monthly or just one time. You can specify the days of week and time periods that it runs to limit processing to off-hours. Select the databases and directories (including subdirectories) to manage with support for workgroup security and database passwords.

Includes a Windows Service for Secure Processing and Reliability

Once defined, the events and tasks can be run by our Monitor program that is a standard Windows program.

Alternatively, Total Visual Agent includes a Windows Service, so you can run your tasks without having anyone logged on the machine. The Windows service is a more secure, robust solution since it can automatically restart if the machine reboots.

New Features in the 2013 Version

A huge number of new features were added in this 2013 release from the previous 2007 version:

  • Microsoft Access 2013Support for Microsoft Access 2013 and 2010, plus 2007
  • Support for 64 bit Operating Systems
  • Simplified Startup and Easier Management of Multiple Microsoft Access Versions
  • Import Settings from Multiple Versions of Total Visual Agent
  • Test All Actions for an Event, Database, Directory or Task Group
  • Create Events that Run Every X Minutes
  • Create Events that are Limited to Periods Spanning Midnight
  • Process Directories with Managed Databases
  • Data Extract Tables are Keyed
  • Run Macros for Database Password Protected Databases
  • Pause for a Fractional Minute
  • Compressed Archive File Names Support Multiple Extensions
  • More Detailed Activity History Log with Deletions
  • More Detailed Database Statistics with Deletions
  • Add Your Comments to Events, Directories, and Actions
  • Simplified Addition of New Actions
  • More Modern and Improved User Interface
  • New User Manual and Help File

For complete list, visit: New Features in Total Visual Agent 2013

Download a Free Trial Version

A fully functional trial version is available for download so you can run it on your system with your databases

Contact Us

  • Visit our Support Site if you would like to submit any questions to our technical support team.
  • Place an order online. Existing customers can upgrade at a discounted price.
Dec 15

Who Thinks the Relaunched Healthcare.gov Performance Metrics are Acceptable?

Healthcare.gov

HealthcareTechnical Evaluation of the Relaunched Healthcare.gov Web Site

On December 1, a updated version of Healthcare.gov was deployed which offers considerable improvements over the original October 1 launch. The administration and contractors issued some press releases and the general public and press just accepted it without really understanding the technical issues. Here’s my technical assessment of the published statements.


My Assessment of Healthcare.gov, Version 1, on October 1

As I described in my original blog post about Healthcare.gov, the site on October 1 was a technical disaster. I received a lot of criticism with my original assessment from those who thought I had a political agenda against ACA or people who simply wished the site was functional independent of the facts.

My assessment on October 1 was eventually vindicated. It took a few weeks for the media, general public, and administration to recognize that the issues were far more problematic than the politically attractive excuse of having too many users.

Will the Contractors Ever be Held Accountable?

The contractors who built the system didn’t seem to know what they were doing and didn’t prioritize the need to build a functional system. I wrote a blog post summarizing how these large IT government contractors often abuse taxpayers: Too Big to Fire: How Government Contractors on Healthcare.gov Maximize Profits

Unfortunately, the contractors who delivered the flawed system on October 1 were rewarded with additional contracts and funds to fix the mess they created. Our federal government procurement process actually gives them more money from their failure than if they did a good job. It’s no wonder that large IT government contractors continue to deliver technically mediocre results. As long as they make sure their lawyers are more powerful than the government lawyers, they can deflect ALL blame so they can continue to use their “unblemished” past performance to go after new contracts. We will see if any of the contractors here are held accountable for this fiasco when they seek future business. This contractor behavior extends across all branches of government.

It would be amazing to interview the developers who actually worked on the original project, discover what their prior experience was, what they were being paid, and how much the taxpayers were billed for their “expertise”. The contractors are enforcing confidentiality rules to prevent those people from talking to the press in the “interest” of protecting taxpayers. I thnk it’s pretty clear which interests they’re trying to protect.


Enhancements in Version 2

When the administration recognized the technical disaster, they brought in Jeff Zients to lead the disaster relief team. It’s a small world. Mr. Zients and I actually worked at the same firm (SPA/Mercer) before I started FMS, though I left a few years before he joined. Through his leadership, he added some experienced people and reorganized the team while using the same contractors. They issued a Progress and Performance Report which summarized their work:

  • System Stability: Uptime consistently above 90%
  • Reduced Error Rates: per page system time outs or failures from 6+% to 0.75%
  • System Capacity: 50,000 simultaneous users, 20-30 minutes per user for 800K per day
  • Software Fixes: 400+ Bugs Eliminated
  • Hardware Upgrades
  • Real-time Monitoring: Dedicated team focused on site monitoring and instant incident response
  • Improved Response Times: from 8 seconds to under 1 second
  • There was also Improved Window Shopping for users.

To a layman, these results seem adequate. To anyone familiar with commercial software development, they are far below what we or any of our clients would consider acceptable. This is not what professional software developers should deliver, nor what taxpayers should accept.

Review of Relaunch Accomplishments

I’m quite surprised others haven’t provided a technical review of the December 1 relaunch:

System Metrics: 90% up time (One Nine Availability is Awful)
Why do people think 90% availability is acceptable? Even their data showing 95% is awful for a web site. That’s not equivalent to an A in class.

90% up time means it’s down 10% or 2.4 hours per day. 95% is still down an hour. Most web sites have hosting uptime based on the number of 9’s. For instance, 3 nines means 99.9% up time. There are 8760 hours per year (365 days x 24 hours per day). A 99.9% availability means it’s down 8 hours a year. 99.99% availability is less than one hour down per year. High volume commercial web sites strive for 5 nines or less than 10 minutes of down time per year.

I have never heard of any web site or client expecting or satisfied with one 9 availability.

Error Rates Below 1% is Still Pretty Bad
99% sounds good for a class exam, but it’s not good for software. How can a production web site have a 0.75% error rate? The rate seems to be based on the number of pages which is far worse than users. If it’s based on users, with the 50,000 capacity, that’s 375 errors. But when it’s based on pages, assuming each user goes through 50 pages, 18,750 of their 2.5 million pages fail. That means 37.5% of users crash (18,750 divided by 50,000).

Of more concern is the cause of the errors. Software either works or it doesn’t. It doesn’t randomly fail. Is the platform failing 0.75% of the time without knowing why? That would be disturbing and could indicate lots of different bugs. If the contractors don’t know what’s causing the crashes in their buggy code, that raises very serious security implications.

Or do they know if people perform certain tasks that the system will always crash, and they expect people to do that only 0.75% of the time? Still not good, but better.

Beyond crashing bugs, the site may run without crashing but fail to perform properly such as the problems submitting accurate data to the insurance companies. Those non-crashing failures aren’t even part of this error rate which is already too high for a production system.

Capacity of only 50,000?
This is a very strange metric. One usually measures website traffic based on number of page views or transactions. The number of users can be supported by adding more bandwidth and instances of the application on more servers. The capacity issues comes from what people are doing. If they are browsing static pages (not entering data), the number of simultaneous users should be much larger. Even if they are entering data, the capacity to save the data should be much higher than 50,000.

It’s not clear what is causing the 50,000 bottleneck. It shouldn’t be the front-end web application. That should be designed to efficiently save user inputs. The users aren’t entering a lot of information in the grand scheme of data entry systems.

A well designed application would separate the real-time user experience from the more capacity constrained data lookup requirements that may have bottlenecks caused by slow legacy systems at the IRS, HHS, INS, etc. This simply means that the user would enter their information quickly, the system would process it offline, and an email would notify them when the verifications were complete.

Capacity Limitations are Odd
The Healthcare.gov web site begs the use of a commercial cloud provider that can automatically support the fluctuating volumes of users. A web site needs to accommodate the largest number of users, not the average. The large volume spike is ahead of us on the deadline date December 23rd. Volumes would drop considerably after that. By using a commercial cloud provider like Microsoft Azure or Amazon EC2, there would be no need to buy hardware to accommodate huge spikes in users or unnecessary after peak times.

We suspect it’s more profitable for the contractors to buy the extra hardware and configure it poorly than to use commercial cloud providers who would provide a better service for lower costs and profits. The contractors may have also implemented features that for “security reasons”, prevent the use of a commercial cloud provider. It could have justified the creation of their own private system even though it probably decreased security given the crashes they’ve experienced.

Software Fixes and Test Plan
Fixing over 400 bugs is obviously a very good thing, but is that enough? How did so many bugs slip through a Test Plan? And what critical bugs remain that they decided not to fix?

  • What was the test plan before October 1?
  • Were the tests conducted and what bugs were known before October 1?
  • How did they decide to release Healthcare.gov with those bugs?
  • How many bugs were found after October 1 and how were they identified?
  • Is the current Test Plan adequate?
  • What bugs were allowed in the relaunched version?
  • How are known and new bugs being handled?

Software development never reaches perfection but a good test plan covers the expected extremes to ensure the features work, unexpected errors are gracefully trapped, the system is scalable to support the expected number of users, and the site is secure.

In our experience, buggy software inevitably creates and reveals more bugs as bugs are addressed. Known problems with transmitting data to the insurance companies were already acknowledged. This implies this final step of the process was poorly tested, probably because all the preceding steps were failing. This would indicate many unknown issues that still need to be found and fixed.

If the original developers didn’t know what they were doing, trying to fix their work could be a waste of time. An experienced development team may be able to create a better solution in less time than fixing shoddy design and code from unqualified personnel.

Hardware: Do they Have Development, Testing and Staging Platforms?
The only reason I can see for such low availability is the lack of proper development, testing and staging environments. When we create web sites, our software developers need their own hardware to create and test their work without disrupting the production system. Testers need a separate platform to do their work and report back to the developers about the problems they encounter. And a staging site is necessary to review what’s about to be deployed. When the decision is made to release the new version, a switch can be made to make the staging site the new production one. In a modern host, the switch can be done almost instantaneously. Maybe it’s down for a short period to verify the new site is working, but it’s not down for extensive testing because the testing and staging environments already handle that.

Based on the information before the October 1 debut, it was clear that the standard software environment of development, testing, staging and production did not exist. How the managers of the project could have neglected this fundamental part of software development is beyond me, especially for the amount of money spent to build this site.

Without the proper platforms, it indicates the people didn’t even consider how they’d enhance and maintain the system over time, and further supports my contention that the people who created and managed this website had never been paid to build commercial database web sites before.

It really is software malpractice to not have the proper development, testing, staging and production platforms in place. The contractors should be liable for such neglect and reimburse the taxpayers.

Why Wasn’t the Site Redesigned for Simplicity, Performance, Scalability and Security?
There were many opportunities to redesign the site to make it more consumer friendly, reduce the amount of development and testing resources, support more users, and improve security. I list these missed opportunities based on what I have seen:

  • The account creation page should be one screen not three. We create multiple pages if entries in one screen impact the following screens. For the Healthcare.gov site, that’s not the case. For instance, if on the first page, you enter an email address that already exists in the system, you’re not told it’s invalid until you finish the third page and are forced to restart. That just adds load on the system. There’s also no need to create a different user name. Why not just use the email address? Most web sites have a one page account creation page, but we understand how having more pages is more profitable to the contractor.
  • The See Plans feature is a huge improvement for shopping. However, when someone finds and wants to buy a plan without a subsidy, there isn’t a way to do so without creating an account in the system. The site should simply direct the customer to the insurance company since the government is not involved with providing a subsidy. In addition to improving the customer experience, that would reduce the load on the Healthcare.gov web site so they can serve more customers. Get them off the site as quickly as possible!
  • There’s no need to ask for information that isn’t directly tied to calculating the subsidy. The “nice to have” questions on race can be discarded to improve response time, reduce the time it takes users to fill out the application form, and increase the number of users the site can support. It also increases capacity.

Conclusions

Over the years, we’ve helped lots of organizations design their software solutions, select technologies, specify architectures, and deliver solutions that are reliable, scalable, secure and maintainable. So much of the Healthcare.gov site seems to remain quite fragile.

I don’t mean to slam the many people worked hard to salvage the awful work of the initial developers. I’m sure they didn’t get to spend much time with their families over Thanksgiving. The relaunched site is definitely much better than the original version. But it only looks good when compared to that technical disaster. Can anyone claim the new metrics are acceptable for an enterprise quality, nationwide public site as important as this?

For more information, read my earlier blog post Too Big to Fire: How Government Contractors on Healthcare.gov Maximize Profits, and a newer post Designing a Data Entry System Properly; Overhauling the Healthcare.gov Web Site.