Re: [sqlite] Sudden DISTINCT parsing failures with perl and sqlite DBD 1.11 / DBI 1.5 / sqlite 3.2.7 /CentOS 4.3 -or- RHEL 4 linux.
m christensen wrote: I don't know if it does or not. I intended to do both, but... I can not get any variant I tried of --select sqlite_version(); -- to execute. It always complained about the statement in one way or another. It does work with the current shell. I'm not sure when this function was added though I think it has been around for a long time. C:\Documents and Settings\DennisC>sqlite3 SQLite version 3.3.5 Enter ".help" for instructions sqlite> select sqlite_version(); 3.3.5 sqlite> BUT Between your help and Mr. Jackson and the ldd tool I found the problem. SQLite.so does indeed use libsqlite3.so.0, in my case. I installed both SQLite 3.2.7 AND the perl DBD library which should both contain all the code and build the required libs. libsqlite3.so was built and installed into /usr/local/lib The problem is the fact it appears my OS came with a copy of SQLite preinstalled, in /usr/lib. Dynamic Linking found that one first. Problem solved, Thanks everyone. Good to hear your problem is solved.
Re: [sqlite] Sudden DISTINCT parsing failures with perl and sqlite DBD 1.11 / DBI 1.5 / sqlite 3.2.7 /CentOS 4.3 -or- RHEL 4 linux.
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 I don't know if it does or not. I intended to do both, but... I can not get any variant I tried of --select sqlite_version(); -- to execute. It always complained about the statement in one way or another. BUT Between your help and Mr. Jackson and the ldd tool I found the problem. SQLite.so does indeed use libsqlite3.so.0, in my case. I installed both SQLite 3.2.7 AND the perl DBD library which should both contain all the code and build the required libs. libsqlite3.so was built and installed into /usr/local/lib The problem is the fact it appears my OS came with a copy of SQLite preinstalled, in /usr/lib. Dynamic Linking found that one first. Problem solved, Thanks everyone. Marc
Re: [sqlite] Sudden DISTINCT parsing failures with perl and sqlite DBD 1.11 / DBI 1.5 / sqlite 3.2.7 /CentOS 4.3 -or- RHEL 4 linux.
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
Re: [sqlite] Sudden DISTINCT parsing failures with perl and sqlite DBD 1.11 / DBI 1.5 / sqlite 3.2.7 /CentOS 4.3 -or- RHEL 4 linux.
[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
Re: [sqlite] Sudden DISTINCT parsing failures with perl and sqlite DBD 1.11 / DBI 1.5 / sqlite 3.2.7 /CentOS 4.3 -or- RHEL 4 linux.
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.
It is issues like this that make me tend to use static linking
instead of shared libraries...
--
D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] Sudden DISTINCT parsing failures with perl and sqlite DBD 1.11 / DBI 1.5 / sqlite 3.2.7 /CentOS 4.3 -or- RHEL 4 linux.
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.
It ACTS like it is older than 3.2.6 in that
count(distinct(expression)) does not work.
Now What?
m christensen wrote:
OK, the DBD 1.11 install creates a SQLite.so Library.
There is ONE in the perl site install directory.
The is another one burried down in /home which perl SHOULD not find
The strings command finds version 3.2.7 in BOTH files.
Where else could perl possibly be finding a SQLite library?
m christensen wrote:
My Perl code reports version 3.2.2from $dbh->{sqlite_version}
My sqlite header file in the sqlite DBD 1.11 install dir clearly
states 'IT' is 3.2.7.
The DBD 1.11 install built fine, tested perfectly and installed
without errors.
There must be an older one that came with the OS install or something
which perl is finding first.
Thanks.
Dennis Cote wrote:
m christensen wrote:
I have a linux machine that saw one-to-many power outages.
I got a backup of everything and reinstalled it.
I have some code that uses Perl DBI and connects to several Oracle
Databases and builds several local sqlite databases.
It pulls a lot of data from Oracle and builds several hundred Meg
of sqlite tables before this failure.
I have the following code which HAD worked for months.
select count(distinct(rec_key))
from test_rows
where list = 'A';
Now it suddenly fails with aPrepare failed near 'DISTINCT' :
syntax error(1) at dbdimp.c line 269 error.
The code runs just fine with the same database file using the
sqlite command line tool.
I tried upgrading DBI from 1.48 to 1.5.
I tried downgrading the sqlite DBD to 1.09 (Which is what I THINK I
was running before), nothing helps.
Ideas.
It sounds familiar but I can't find any references for the life of
me...
SQLite has only supported the count(distinct(expression)) since
version 3.2.6.
I suspect that you have restored to an earlier version. You can
check the library version by executing
select sqlite_version();
HTH
Dennis Cote
Re: [sqlite] Sudden DISTINCT parsing failures with perl and sqlite DBD 1.11 / DBI 1.5 / sqlite 3.2.7 /CentOS 4.3 -or- RHEL 4 linux.
OK, the DBD 1.11 install creates a SQLite.so Library.
There is ONE in the perl site install directory.
The is another one burried down in /home which perl SHOULD not find
The strings command finds version 3.2.7 in BOTH files.
Where else could perl possibly be finding a SQLite library?
m christensen wrote:
My Perl code reports version 3.2.2from $dbh->{sqlite_version}
My sqlite header file in the sqlite DBD 1.11 install dir clearly
states 'IT' is 3.2.7.
The DBD 1.11 install built fine, tested perfectly and installed
without errors.
There must be an older one that came with the OS install or something
which perl is finding first.
Thanks.
Dennis Cote wrote:
m christensen wrote:
I have a linux machine that saw one-to-many power outages.
I got a backup of everything and reinstalled it.
I have some code that uses Perl DBI and connects to several Oracle
Databases and builds several local sqlite databases.
It pulls a lot of data from Oracle and builds several hundred Meg of
sqlite tables before this failure.
I have the following code which HAD worked for months.
select count(distinct(rec_key))
from test_rows
where list = 'A';
Now it suddenly fails with aPrepare failed near 'DISTINCT' :
syntax error(1) at dbdimp.c line 269 error.
The code runs just fine with the same database file using the sqlite
command line tool.
I tried upgrading DBI from 1.48 to 1.5.
I tried downgrading the sqlite DBD to 1.09 (Which is what I THINK I
was running before), nothing helps.
Ideas.
It sounds familiar but I can't find any references for the life of
me...
SQLite has only supported the count(distinct(expression)) since
version 3.2.6.
I suspect that you have restored to an earlier version. You can check
the library version by executing
select sqlite_version();
HTH
Dennis Cote
Re: [sqlite] Sudden DISTINCT parsing failures with perl and sqlite DBD 1.11 / DBI 1.5 / sqlite 3.2.7 /CentOS 4.3 -or- RHEL 4 linux.
My Perl code reports version 3.2.2 from $dbh->{sqlite_version}
My sqlite header file in the sqlite DBD 1.11 install dir clearly states
'IT' is 3.2.7.
The DBD 1.11 install built fine, tested perfectly and installed without
errors.
There must be an older one that came with the OS install or something
which perl is finding first.
Thanks.
Dennis Cote wrote:
m christensen wrote:
I have a linux machine that saw one-to-many power outages.
I got a backup of everything and reinstalled it.
I have some code that uses Perl DBI and connects to several Oracle
Databases and builds several local sqlite databases.
It pulls a lot of data from Oracle and builds several hundred Meg of
sqlite tables before this failure.
I have the following code which HAD worked for months.
select count(distinct(rec_key))
from test_rows
where list = 'A';
Now it suddenly fails with aPrepare failed near 'DISTINCT' :
syntax error(1) at dbdimp.c line 269 error.
The code runs just fine with the same database file using the sqlite
command line tool.
I tried upgrading DBI from 1.48 to 1.5.
I tried downgrading the sqlite DBD to 1.09 (Which is what I THINK I
was running before), nothing helps.
Ideas.
It sounds familiar but I can't find any references for the life of me...
SQLite has only supported the count(distinct(expression)) since
version 3.2.6.
I suspect that you have restored to an earlier version. You can check
the library version by executing
select sqlite_version();
HTH
Dennis Cote
Re: [sqlite] Sudden DISTINCT parsing failures with perl and sqlite DBD 1.11 / DBI 1.5 / sqlite 3.2.7 /CentOS 4.3 -or- RHEL 4 linux.
m christensen wrote: I have a linux machine that saw one-to-many power outages. I got a backup of everything and reinstalled it. I have some code that uses Perl DBI and connects to several Oracle Databases and builds several local sqlite databases. It pulls a lot of data from Oracle and builds several hundred Meg of sqlite tables before this failure. I have the following code which HAD worked for months. select count(distinct(rec_key)) from test_rows where list = 'A'; Now it suddenly fails with aPrepare failed near 'DISTINCT' : syntax error(1) at dbdimp.c line 269 error. The code runs just fine with the same database file using the sqlite command line tool. I tried upgrading DBI from 1.48 to 1.5. I tried downgrading the sqlite DBD to 1.09 (Which is what I THINK I was running before), nothing helps. Ideas. It sounds familiar but I can't find any references for the life of me... SQLite has only supported the count(distinct(expression)) since version 3.2.6. I suspect that you have restored to an earlier version. You can check the library version by executing select sqlite_version(); HTH Dennis Cote
[sqlite] Sudden DISTINCT parsing failures with perl and sqlite DBD 1.11 / DBI 1.5 / sqlite 3.2.7 /CentOS 4.3 -or- RHEL 4 linux.
I have a linux machine that saw one-to-many power outages. I got a backup of everything and reinstalled it. I have some code that uses Perl DBI and connects to several Oracle Databases and builds several local sqlite databases. It pulls a lot of data from Oracle and builds several hundred Meg of sqlite tables before this failure. I have the following code which HAD worked for months. select count(distinct(rec_key)) from test_rows where list = 'A'; Now it suddenly fails with aPrepare failed near 'DISTINCT' : syntax error(1) at dbdimp.c line 269 error. The code runs just fine with the same database file using the sqlite command line tool. I tried upgrading DBI from 1.48 to 1.5. I tried downgrading the sqlite DBD to 1.09 (Which is what I THINK I was running before), nothing helps. Ideas. It sounds familiar but I can't find any references for the life of me...
