APB Reports has released a new viewer called CR Dispatch. CR Dispatch takes a different approach to viewing your reports, since it has a minimal user interface that only appears the first time you run a report. After that it provides a secure way to run a specific RPT with one click.

The first time you run the application (.EXE) it asks you to select an RPT file. It then creates a config file that stores the report name and (optionally) the credentials used to run it. The next time you run that .EXE it silently runs that same report with the stored credentials. This means that you need multiple copies of the EXE file, one for each report you want to run. The EXE and RPT are stored together in a folder, with a separate folder for each RPT file. This works best for users with a small number of reports to run, or if you are setting up reports for a user and want a very simple setup.

Here is a demo video of CR Dispatch in action.

Two customers contacted me in the past few days about the following Microsoft updates.

• KB4041676 for Windows 10
• KB4041681 for Windows 7/8

These updates broke reports that use the ‘classic’ Microsoft JET drivers to read ‘classic’ xls spreadsheets. ‘Classic’ here is a euphemism for ‘ancient but still working’, like my workhorse Office XP from 2002.

Today I got a similar error when I tried to help a customer import a spreadsheet(xls) into an MS Access database (mdb). MS Access failed with the following error:

“The wizard is unable to access information in the file….”

So I tried to read the same spreadsheet from Crystal Reports using the DAO connection method, and got this error:

“Unexpected error from external database driver (1)”

I checked and found that KB4041681 had been installed on that workstation.

The official Microsoft temporary solution is for us to use a different “OLEDB provider” in place of JET, but that only works if you can use OLEDB and/or  choose your provider.

So I did some research and found a post from 2008 where someone was getting this error message. They asked why they could only read xls files when those files were already open in Excel. If the file wasn’t open in Excel he would get the same errors I mentioned above.  I figured it couldn’t hurt to do a quick test so I opened the file in Excel and then tried to read it from MS Access.  It worked for MS Access imports and also worked for Crystal Report connections. Both would work as long as the xls file was open in Excel. Both would fail with the errors above when the file wasn’t already open in Excel.

This isn’t a great solution, and hopefully Microsoft will fix the issue in the near future. But in the meantime this workaround might just help someone meet a deadline. If you try this, let me know if it works in your environment.

Update 10/19/2017

One of my readers pointed me to the dll that causes this error and how to roll back just that one dll.  I now see that this is one of several solutions found in the MSDN discussions.  See the links below for more information:

MSDN blog article: Unexpected error from external database driver

MSDN forum thread: ODBC Excel Driver Stopped Working…

Find it EZ (search and documentation) has recently partnered with rePORTAL (scheduling and distribution), which means some new Find it EZ features and some discounts for rePORTAL customers. Find it EZ now directly integrates with the rePORTAL scheduling database. This allows rePORTAL users to extract scheduling information (run times, recipients, destinations, etc.) into user-friendly spreadsheets and also to search and document changes in the underlying database model.

rePORTAL customers can also get a 20% discount on any new license purchase of the latest Find it EZ products, by using the discount code “rePORTAL” at checkout:

Code Search Pro ( Server only )

Dev Surge 365 Enterprise

You can read the full press release here.

In recent years, I have been doing lots of SQL command-based reports, which means writing lots of queries in every imaginable flavor of SQL. It was initially frustrating trying to keep the syntax changes straight and I got tired of doing web searches for the same functions over and over.

My solution was to create a “cheat sheet” grid to store my most commonly used SQL functions and the correct syntax to use in each of the database platforms. Once I looked up a function, I would add it to the grid and now the grid answers most of my questions. There are about 40 functions listed and I have most of them completed for the 7 flavors of SQL I see most (plus Crystal Reports formula syntax):

• Microsoft SQL Server
• Oracle
• MySQL
• Pervasive
• Progress
• PostGre SQL
• MS Access

I have empty columns for Providex and DB2. They are empty because I haven’t had any recent projects on those platforms and don’t have an environment where I can experiment.

I hope some of you will find this grid useful. You can also share the file with others as long as you leave the heading in place. If any of you want to fill in some of the gaps or suggest an improvement, your contributions would be appreciated.  And thanks to John Pelot of Skyward, Inc for filling in many of the progress functions.