c++visual-c++nanodbc

nanodbc error LNK2019: unresolved external symbol - on basic connection


I am attempting to connect to a MySQL database using ODBC driver using nanodbc library a C++ wrapper for ODBC but I am getting error LNK2019: unresolved external symbol

I have added the path to installed library directory in additional library directory where nanodbc.lib is located. I even copied nanodbc.lib in my source directory but still no luck.

I had added nanodbc.lib to Properties->Linker->Input->Additional Directories in case #pragma comment(lib, "nanodbc.lib") was not working but its still not working.

The worst part is the same code works in an existing project (having different connection string).

Tooling : Microsoft Visual Studio Community 2017 Version 15.9.11

Package Manager : vcpkg

OS : Windows 10 Professional 64-bit

Language Standard : C++17

Code :

#include <iostream>
#include <nanodbc/nanodbc.h>

#pragma comment(lib, "nanodbc.lib")

int main()
{
    nanodbc::string dns = "PLC_Interface";
    nanodbc::string user_name = "root";
    nanodbc::string password = "rooot";
    nanodbc::connection conn(dns, user_name, password);
    std::cout << conn.connected() << std::endl;
    //std::cout << "Database Name : " <<conn.database_name() << std::endl;
    //std::cout << "DBMS Name : " <<conn.dbms_name() << std::endl;
    //std::cout << "DBMS Version : " <<conn.dbms_version() << std::endl;
    conn.disconnect();
    std::cout << conn.connected() << std::endl;
}

Error :

error LNK2019: unresolved external symbol "public: __cdecl nanodbc::connection::connection(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,long)" (??0connection@nanodbc@@QEAA@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@00J@Z) referenced in function main

Solution

  • Solved the problem. The issue was with library created by vcpkg package manager. When I built the library myself manually, the issue got resolved. No code change was necessary (even working with #pragma).


    Wanting to know is their any way to compare the libraries to find out why the issue was caused in the first place?