m christensen wrote:
[EMAIL PROTECTED] wrote:
m christensen <[EMAIL PROTECTED]> wrote:
Ok, more info....
The SQLite.so library in the perl site install directory is version
3.2.7 from looking at the strings in the binary itself.
If I rename that file so as to 'hide' it the perl code falls over
dead as it can't find it.
SO.... I have a library that I NOW it is using which:
Claims to be 3.2.7 according to the source code.
Claims to be 3.2.7 according to the compiled lib strings.
BUT It Returns 3.2.2 from the $dbh ->{sqlite_version} function.
You are not loading the library you think you are. If the
source code says 3.2.7 then $dbh->{sqlite_version} will too.
That is why this is SOOO frustrating.
There is absolutely no question it's using the library in question (at
least in some way).
If I MOVE the SQLite.so file (Which contains 3.2.7) the script fails,
stating the SQLite module
is not installed correctly.
When I put it back, it works, and internally claims it's version 3.2.2
Are you sure that $dbh0>(sqlite_version) returns the same thing as
executing the following SQL:
select sqlite_version();
I don't use perl, so I'm not sure how you actually execute the query.
One other possibility, you may have a wrapper that is statically linked
to an older library and the SQLite.so dynamic library may not be used.
Finally, shouldn't the library name be sqlite3.so or libsqlite3.so?
Dennis Cote
