Set the charset in freetds.conf

I’m building an API in Laravel that has to interact with an MSSQL database. This requires that I use freetds as the database communication library.

The database contains years of data from all kinds of input sources, probably including copy/paste from MS Word, and some of the characters can’t be processed as JSON if taken “as is” without character set identification.

I discovered this when a new endpoint was crashing with a 500 server error. After xdebugging the problem right down into Laravel’s core, I found that the Response object, in building its output, was NULLing my data when trying to JSONify it in morphToJson(). So when this processed content gets passed to setContent(), it fails the is_callable(array($content, '__toString')) test and throws an exception.

I had already suspected this was an encoding problem, so I’d found the solution buried, and apparently ignored, here:

Quite simply, in your freetds.conf, in the [global] settings area, set client charset = UTF-8.

And done. The funky characters are correctly interpreted, don’t NULL the JSON, and don’t crash the API.

Why an API?

I was recently asked to provide some basic notes on what an API is and why one might want to develop or work with them. Having embarked on my own exploration of the topic only a few months ago, the following thoughts are probably naive and certainly incomplete. But they’re my current first-order approximation of an answer to the question, “why an API?”

Continue reading