Currently SQLString wraps std::string - it's just have the property of that type, and even provides operators to get reference to the internal object. That is wrong in many ways. First, it's template class, and for application and connector it may be a different class. Also, std::string may have different size for release and debug version.
The visible problem with current design is numerous compilation warnings with VS, that std::string is not exported.
Other things we need to keep in mind is that this class is used for exchange of data between application and library, and it is one of the main means of that exchange. Plus the class is used internally, and internally it may need to access to the string implementation(i.e. to std::string object) to feed other stl functions, e.g. regexp.

What has to be done.

1) Operators exposing underlying std::string to applications has to be removed. Additional task will be to provide this access to the connector internally in some new way
2) std::string property has to be either substituted with (smart) pointer, or hidden completely in new class, say StringImplementation, that will be pimpl'ed - can be smart pointer again. Hiding implementation has benefit that application won't ever notice the change in implementation.
3) Constructor from std::string needs some attention. Maybe changed or removed.

Some things to consider.

Providing internally access to the string implementation can be organized in different ways, and maybe should be put as separate item here. Options are - some friend class, some class extending SQLString for internal use, use internally of StringImplementation or std::string itself, and corresponding constructor should probably avoid excessive data copying
Connector returns string data by values. That reasonable to provide move constructor.
Regarding not exporting VS warning, that will persist in case of unique_ptr - i think it can be suppressed. The other way worth of consideration is not exporting the whole SQLString class, but all (required) methods individually.