If you’re considering the recent (Feb 2019) updates to CF11 or CF2016, and you still use the ColdFusion ODBC services feature, beware of a known issue that may keep those two CF ODBC services from running after the update. This issue has plagued some folks since the Sep 2018 updates and does remain in the latest updates from last week (released Feb 22).

UPDATE: This issue was fixed in The June 2019 updates to CF11, 2016, and 2018 (updates 19, 11, and 4), respectively. See the bugs fixed”page for each. I leave the rest here for posterity and for the sake of completeness. . 

Fortunately, the release notes for those latest updates (for CF11 update 17 and 2016 update 9) acknowledge the problem and propose a solution in their “known issues” section (quoted below) which you can apply by hand, either by recovering a needed file from the update backups, or by downloading the file from Adobe.

Note that the issue does not appear to have affected CF2018 users (per the link to past discussion, offered above), and it’s not mentioned as a known issue in the docs for CF2018 update 2.

For CF11

First, here is what’s indicated about this in the known issues for CF11 update 17:

CodFusion 11 ODBC Server service does not start in some cases if the file msvcr71.dll is missing.

Workaround

Copy the file msvcr71.dll from the backup folder CF_HOME/cfusion/hf-updates/hf-11-000<update_number>/backup/db/slserver54/bin to:

[CF_HOME]cfusiondbslserver54bin
[CF_HOME]cfusiondbslserver54admin

If the file does not exist in the backup, download the file and copy it to the locations mentioned above.

For CF2016

And here is what’s indicated in the known issues for CF2016 Update 9:

Issue #1

ColdFusion (2016 release) ODBC Server service does not start in some cases if the file msvcr100.dll is missing.

Workaround

Copy the file msvcr100.dll from the backup folder CF_HOME/cfusion/hf-updates/<update folder>/backup/db/slserver54/bin to:

[CF_HOME]cfusiondbslserver54bin
[CF_HOME]cfusiondbslserver54admin

If the file does not exist in the backup, download the file and copy it to the locations mentioned above.

Closing thoughts, possible future resolution

While the problem was reported by users of those previous Sep 2018 updates to CF11 (update 15) and 2016 (update 7), it was not documented this way until the latest updates (not even in the failed/removed updates from Feb 12, updates 16 and 8, respectively). Even so, it’s reasonable to presume that these steps would work for those somehow choosing to implement only those Sep 2018 updates.

And if it somehow turns out that this issue CAN affect those on CF2018, I would hope to update this blog post to reflect that. I welcome comments below.

Finally, as for an explanation and ultimate resolution to the problem, an Adobe engineer replied when I asked about it in the CF blog about the most recent updates (click “reply” there to see replies to that comment):

“Removing the dll files was a recommendation from Data Direct when they provided us new drivers in the last update cycle, so we had to replace the same with newer versions of the dll files. We are following up with data direct on this.“

So hopefully some better resolution (to prevent the problem in the first place) will come in time. Until then, the workaround above should help some.

Since this issue has still caught some people off-guard this week (if they missed this as a documented known issue with a fix), I wanted to draw it out here, in case it may help some more likely to see and know about it.

Postscript: Should you still be using ODBC?

Some readers may want to ask why this is even an issue, asserting that “surely the time for ODBC is past”.

I know some orgs who explain that they DO need it and MUST use ODBC still, for “legacy reasons”. But I will say that in my experience it’s rare that there’s a compelling need for it which can’t be offered by some other more recent alternative, whether that’s about a CFML feature, an alternative database drivers, or the like. (And I can help you consider that, if you’re in that boat.)

Are you REALLY still using ODBC? You’re positive?

Ok, so some people really are using ODBC. But I’m telling you, sometimes people are running the CF ODBC services when they really, truly do NOT need to be running those CF ODBC services at all. Let me explain.

I help people daily in installing updates and new versions of CF, and when they see the offer in the CF installer to enable the ODBC services, I also ask if they really need it, and if they say “yes”, I ask why. Usually they think I’m asking a stupid question, and they answer “because we use CF to talk to databases”. This often reflects a long-held misunderstanding on their part.

So I will ask if we can look at their previous CF installation Admin to see its datasource setup, or some other CF installation they may have (or if nothing else, the neo-datasource.xml file from a previous install, if that may be all they have). And we nearly always see that all they have for datasources are ones for MySQL, SQL Server, Oracle, or the like. Those do NOT use ODBC. They use JDBC. It’s an understandable point of confusion. And in that case, they do NOT need the CF ODBC services.  They do not need to install them, or if installed they can stop the services and set them to “manual” (in the Windows Services panel).

It’s indeed true that CF used to use ODBC for all database connectivity–prior to CF6, released in 2002(!), but since CF6, the default means for most CF database processing has been instead JDBC (and it’s transparent to us in CFML and indeed in the Admin).

That said, there is indeed still support for ODBC in the CF Admin Datasources page (in CF2018, even) with the available an “ODBC socket” driver type. So yes, ODBC can be used, and these ODBC services support that (and the Microsoft Access driver type, I believe). And some swear they still need it.

But really, ODBC support is hanging on by a thread. It really is past time to seek alternatives, if you do feel you MUST rely on it. Just a word to the wise. (I do not work for Adobe or represent their opinions or future plans.)