We don't. The issue here is that our Manager classes create connections without the encoding settings.
For example `ReverseManager.php:222` -- here is something like that missing:

```php

$con = ConnectionFactory::create(
    array(
        'dsn' => $buildConnection['dsn'], 'user' => $username, 'password' => $password,
        'settings' => array('charset' => $this->getGeneratorConfig()->getBuildProperty('databaseEncoding'))
    ),
    AdapterFactory::create($buildConnection['adapter'])
);
```

Other Manager classes create the connection on its own as well (=duplicate code). We should consolidate that stuff into AbstractManager. 

But another question is: How do we handle wrong encoding? When tables are defined through MySQL Workbench and servers's default encoding is not utf8 for example it's likely that descriptions texts are in latin. When the buildProperties are set then to utf8 then it won't work.
What if the developer created tables at the very beginning with latin1 and then recognized that he was wrong *then* changed to utf8 -- those description encoding would be mixed.
Am not sure if we should handle and automatically fix those cases or should just presume that the developer configured the properties well and database's content is appropriate.
If not we should throw a meaningful exception when we detect encodings that is different than the current.

So, a `utf8_encode` call is necessary when database is not configured as utf8 (which may be legit), but that call depends on the current encoding of the database (which can only be retrieved during runtime/extra query).
Since we'd only need those checks in our Manager classes we should place there a method like `getConnectionEncoding` that calls a equal method on Adapter classes to be cross database compatible. Then we're able to check if we have utf8 data and are able to handle the simplest case of having different encoding than utf8. Mixed encodings are still not handled then.