Sunday, July 31, 2011

Guide: Fixing Spell Check French Edition

Recently we had a customer call us regarding a problem with spell check.  Interestingly it had switched to French without any option to switch back to English. This problem occurs due to an issue with installing Office 2007 which replaces files that are incompatible with Outlook Express.

Two fixes are available at this time.

Fix #1 -

Install Windows Live Mail - download is available at http://download.live.com/wlmail

Fix #2 -

Install a 3rd party spell check program. You can find numerous free programs from Microsoft Communities site. http://www.microsoft.com/communities/default.mspx After installing a 3rd party app you should see it available on the spell check language drop down.

Wednesday, July 27, 2011

Software developer extemists

As a consulting firm and support provider we often find ourself in very odd situations being a liason between a software developer and an end user.  Under most circumstances end users have a very limited set of needs, they need to be able to type a letter, keep a spreadsheet, correspond by email and of course print their data. The vast majority of computer users today will utilize Word, Excel and maybe a book keeping application like Quicken or Quickbooks. Many of our customers will take tasks that may be more easily accomplished in another application and force fit them into an application that wasn't really designed for it but the customer knows how to "make it work". 

Of course there are customers who need a more vertical application. These applications can include industry specific niche applications such as Mitchell OnDemand (car industry), Medisoft (medical practice management), or AutoCAD (drafting and engineering).  For the most part these software providers are reasonable. Occasionally we run into some oddities but as time as went on the small developers have been bought or just folded up shop and went away.  Today we're going to discuss the worst case scenarios and the fruit cakes of the world - without naming to many names of course.  This is just some things to be aware of if you're researching software for a specific business need.

Recently we came across a software vendor with very specific requirements, many of which are just good practice for any software company. They should specify minimum hardware that more than exceeds the reality of what their software runs on. This prevents a customer from getting "cheap" and thinking that Best Buy is the solution to all their needs.  For example specify Windows 7 Professional with 4gb RAM for a workstation and Windows 2008 with 4gb or 8gb for a server. 

The real issue becomes when software developers go what I will refer to as out of bounds. What exactly is out of bounds?  Specifying a specific model of printer, scanner, copier, or even a modem.  Demanding specific processors or brands of equipment is another gripe.  When you're looking at applications for your business remember that you are the customer. You probably already have a lot of equipment you've invested in and probably a lot of money already spent.  What I like to tell my customers is Windows is Windows. Software developed for Windows should run on Windows. If the underlying computer runs the Operating System then any program that runs on that Operating System should run on that computer. The only exception to this should be if you're not meeting minimum requirements, for example you need more RAM or hard drive space, if you don't the application should run but it may not perform well. Printers and scanners are standardized to Windows now and have been since the early 1990's.  Almost without exception applications will talk to Windows which in turn talks to your printer, very few applications directly address devices. 

So whats the recommendation?  Look around and take advantage of the fact there are likely many choices for what you're trying to do regardless of industry. Ask for trial software and have your IT person install it and test it with everything you have. If a software company gets pushy remember that you're "marrying" them and the relationship will go on and on for years. Your data is locked up and you'll get to much invested to easily switch later. If they push to hard and aren't supporting a wide range of options remember that in the future some of their standards may even become impossible to purchase or worse even they may release updates that require you to move along or lose support.  In short, do your research, its your money and your business.

Sunday, July 24, 2011

Interop and Gembox

We recently began working on a project for a customer that required taking database information and spitting it into an Excel workbook.  The original project was created utilizing a process Microsoft provides called Microsoft Interop. Here is a very brief description - MS Interop allows the programmer to pull data from a database and run a server side Office application such as Excel to generate a spreadsheet.  Basically you request the information and a session of Excel is launched, data is pumped into it then its saved. Think of it as a scripted event.  Microsoft recommends not using this due to security issues, speed issues, and memory issues.

Our customer had complained repeatedly that they were having issues with speed, big issues.  One report they run involving 30 days of data was taking 15 minutes or more, if it ran at all.  Most of the time they were picking up the phone and having the developer run the report locally to avoid the problem. Many smaller reports were taking 5-10 minutes.  These reports do have a lot of information but frankly we didn't believe the story the developer was feeding us that the problem was how much information was being requested and pumped into this Excel Workbook. 

During the process of researching this issue we wound up taking on future development of this project.  The first thing we did (after stumbling through the existing code and getting it working on a new server) was to research and determine the cause of the "slowness" of this Excel Interop.  During our research we looked at server memory, processor power, hard drive speed, internet and network connection types as well as many other sources that could slow down the process. We found that each of these potential bottlenecks was not actually responsible for the problem. That left us with one possible problem - Microsoft Excel Interop.

So now the solution - We began researching third party applications that go about the same work.  We found numerous other ideas to fix the issue. The one we finally settled on is GemBox.Spreadsheet. GemBox essentially does the same thing as Interop, in fact our programmer was able to repurpose much of the code and change the calls to Interop to GemBox.Spreadsheet in order to get the new process working.  GemBox describes their product as being easy to incorporate, fast and 100% non dependent on Excel. We found all of this to be true.

The results?  No less than breath taking. Our reports that were taking well over 15 minutes if they ran at all now take around 2-3 seconds. Yes you read that correctly. 2 as in 1....2...   We were stunned with what we got.  There of course is a catch to this.  GemBox does provide a free version, but larger projects require a license. Prices begin at $480 which honestly we felt was a steal for what it gave us.  The free version is actually quite flexible and in many cases it is all you need - it supports 150 rows per sheet with a max of 5 sheets per workbook. We recommend buying it to support the company that creates it, just as we do with any software you enjoy using.

Rating - 10/10