Thanks. In my case there is no installer as such. My vba code runs
inside the same process as the host cad system. In this case Bricscad
has already loaded their copy of dqlite3.dll and my like-named file
could not demand precedence.
Graham
On 02-11-2018 3:16 am, Simon Slavin wrote:
On 1 Nov 2018, at 10:40am, R Smith <ryansmit...@gmail.com> wrote:
Most applications play nice and do not install their greasy little
DLLs to the Widows DLL common area, but just hug them locally (in the
app folder). But some, thinking probably they were doing the right
thing, do install DLLs to the common area, and sometimes this includes
a DLL like sqlite3.dll which starts causing problems for everyone else
using it, because they don't actually distribute/install newest
versions, so everything else loading the same library gets the last
installed version of the last app to successfully install to the
common area.
That's the problem. The standard Windows installer has a way of
saying "install this common-area DLL if and only if there isn't one in
there, or it's a later version than the one already in there". When
only professionals wrote Windows programs that needed installing, it
was fine, but now days few people use it because
(A) Some DLLs have bugs, the programmer figured this out and wrote
around the bug, but their work-around does't involve a version-check.
Updating the DLL fixes a bug their app depends on.
(B) My installer installs my app which works perfectly. If you have
trouble with another app, take it up with their support team, not
mine.
Now days most houses use Installshield which has its own problems.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
