Closed ISBachvarov21 closed 6 months ago
Looks like a build options mismatch, I'm pretty sure that if you build SOCI yourself your problem would go away.
And I'm sorry, but problems like this are almost impossible to diagnose remotely, you need to ensure that you use the same compiler options for your code as were used for the package and there is nothing we can do about it, so it's not useful to keep this open.
this code snippet generates an access violation reading location from soci-test.exe (libcrypto-3-x64.dll) when
sql.close()
is called or the session object enters its destructor (connection string has been hidden for obvious reasons)what i found is that initializing sql as a session* through the constructor of session and then later on instead of
sql.close()
doingsql = nullptr
doesn't throw, with the only catch being that this is obviously a memory leak (delete sql
beforesql = nullptr
throws the same error)NOTE: doing
free(sql)
works like a charm, so i suppose i'll be using that for now