On Mon, Nov 28, 2011 at 9:21 PM, Adam Kennedy
wrote:
>
> Secondly, for a collection of arbitrary SQLite database files with
> unknown schemas that were created before 3.7.8, is it possible to do
> bulk-processing of the databases to gain the speed improvements of the
> new merge-sort indexing in 3
ch I moderate) and I will let it in. Anyone
on
dbd-sqlite only that is interested in such issues should also join sqlite-users
so they can post to it directly.
-- Darren Duncan
Original Message
Subject: Re: [Fwd: Re: [sqlite] [DBD-SQLite] Re: SQLite bug ticket - build
fails on s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adam Kennedy wrote:
> Unfortunately, we neither have the ability to run configure (as we
> don't have reliable access to /bin/sh or any of the other stuff it
> needs) or the ability to use a pregenerated static configuration
> across all platforms.
We
Apologies, that should be...
http://svn.ali.as/cpan/trunk/DBD-SQLite/Makefile.PL
2010/1/3 Adam Kennedy :
> The build code we're using is run across all operating systems.
>
> You can see the actual build script here.
>
> http://ali.as/cpan/trunk/DBD-SQLite/Makefile.PL
>
> Unfortunately, we neithe
The build code we're using is run across all operating systems.
You can see the actual build script here.
http://ali.as/cpan/trunk/DBD-SQLite/Makefile.PL
Unfortunately, we neither have the ability to run configure (as we
don't have reliable access to /bin/sh or any of the other stuff it
needs) o
Thanks for the comments on the build flags, we will investigate.
The threadsafe disabling may be a result of DBD::SQLite being itself
compiled on a Perl that has threading compiled out (which adds about
10-20% overall speed and is used in certain situations).
Adam K
DBD::SQLite Release Manager
2
On Thu, Oct 15, 2009 at 10:59 PM, P Kishor wrote:
> On Thu, Oct 15, 2009 at 10:52 PM, P Kishor wrote:
>> Because of FTS3 problems with DBD::SQLite 1.26_05, I downgraded to
>> 1.23, but now I get a bus error/segmentation fault, once again, on
>> FTS3 operations.
>>
>> Is there a version of DBD::SQ
On Thu, Oct 15, 2009 at 10:52 PM, P Kishor wrote:
> Because of FTS3 problems with DBD::SQLite 1.26_05, I downgraded to
> 1.23, but now I get a bus error/segmentation fault, once again, on
> FTS3 operations.
>
> Is there a version of DBD::SQLite that is known to have a working
> implementation of F
Please note the following correction to the announcement.
Whining is also welcome. :)
Adam K
2009/10/15 Darren Duncan :
> Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null.
___
sqlite-users mailing list
sqlite-users@sqlite.org
ht
Craig Talbert wrote:
>>From Perl, when I attempt to make a database connection using SQLite,
> I get the following error:
>
> [Tue Jun 23 17:10:22 2009] projectory.cgi:
> DBI->connect(dbname=projectory.sqlite3) failed: database disk image is
> malformed at ./projectory.cgi line 1577
>
> At line 1
Not sure if this will help, running this through the debugger the
error is being generated from DBD::SQLite::db::_login which is in the
XS/C code.
main::getDBConnection(projectory.cgi:1577):
1577: $dbh =
DBI->connect("dbi:SQLite:dbname=projectory.sqlite3","","") or die
"$DBI::errstr\n";
I mean what is benefits of using DBD::SQLite::Amalgamation? Where it
can be needed?
--
Alexander Batyrshin aka bash
bash = Biomechanica Artificial Sabotage Humanoid
On Sun, Sep 21, 2008 at 9:51 AM, P Kishor <[EMAIL PROTECTED]> wrote:
> On 9/21/08, Alexander Batyrshin <[EMAIL PROTECTED]> wrote:
>
On 9/21/08, Alexander Batyrshin <[EMAIL PROTECTED]> wrote:
> Sorry for off-topic.
> What is main difference between DBD::SQLite and DBD::SQLite::Amalgamation?
Exactly what it says on the box. The latter uses the SQLite
amalgamation. The former doesn't. They both work exactly the same for
the end
Sorry for off-topic.
What is main difference between DBD::SQLite and DBD::SQLite::Amalgamation?
--
Alexander Batyrshin aka bash
bash = Biomechanica Artificial Sabotage Humanoid
On Sat, Sep 20, 2008 at 8:04 PM, P Kishor <[EMAIL PROTECTED]> wrote:
> I encountered this problem and solved it, so hop
On 3/31/08, Jim Dodgen <[EMAIL PROTECTED]> wrote:
> It makes ok, here is the output from "make test". the hang is after
> "t/06error" it never finishes
>
> DBD-SQLite-Amalgamation-3.5.7
>
> # make test
> PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
> "test_harness(0, 'blib/l
Hi,
> [...]
>> t/06error...ok 1/2
>>
>> (this never finishes)
>
> well, look in the t directory for the specific test. In my case, I see
> the following --
> [...]
> my $db = DBI->connect('dbi:SQLite:foo', '', '', { RaiseError => 1,
I'm not certain what the call to DBI->connect() d
On 3/31/08, Jim Dodgen <[EMAIL PROTECTED]> wrote:
> On 3/31/08, P Kishor <[EMAIL PROTECTED]> wrote:
> > On 3/30/08, Jim Dodgen <[EMAIL PROTECTED]> wrote:
> > > Any Perl people out there using this yet (version 3.5.7)?
> > >
> > > I'm continually having problems when doing "make test"
> > >
>
On 3/31/08, P Kishor <[EMAIL PROTECTED]> wrote:
> On 3/30/08, Jim Dodgen <[EMAIL PROTECTED]> wrote:
> > Any Perl people out there using this yet (version 3.5.7)?
> >
> > I'm continually having problems when doing "make test"
> >
> > It hangs forever and never completes
> >
> > I have tried this
On 3/30/08, Jim Dodgen <[EMAIL PROTECTED]> wrote:
> Any Perl people out there using this yet (version 3.5.7)?
>
> I'm continually having problems when doing "make test"
>
> It hangs forever and never completes
>
> I have tried this on multiple boxes running both Fedora and Redhat ES,
> all 64 b
Humm... I'll keep looking.
thanks
On 3/30/08, Jim Dodgen <[EMAIL PROTECTED]> wrote:
> Any Perl people out there using this yet (version 3.5.7)?
>
> I'm continually having problems when doing "make test"
>
> It hangs forever and never completes
>
> I have tried this on multiple boxes running both
On 3/31/08, Jim Dodgen <[EMAIL PROTECTED]> wrote:
> Any Perl people out there using this yet (version 3.5.7)?
>
> I'm continually having problems when doing "make test"
Today I tried and installed on Solaris successfully. Both the module
1.14 and sqlite3 amalgamation.
--
Radek
_
s possible here?
Good point. Not sure. Possibly none because only the first statement in the
SQL is compiled.
Thanks!
-Clark
- Original Message
From: Alexander Batyrshin <[EMAIL PROTECTED]>
To: General Discussion of SQLite Database
Sent: Monday, February 4, 2008 8:30:10 P
I think i found solution.
The problem is that DBD::SQlite->disconnect() method execute
sqlite3_close() function.
This function return SQLITE_BUSY in case if there are any active statement.
>From API:
"Applications should finalize all prepared statements and close all
BLOBs associated with the sqlit
Hello,
> What do you expect to see? From the code, I'm guessing something like:
This is "test-case" program for testing DBD-SQLite behavior. Dumper is
only for be sure, that data was read correctly from database.
> If you're just trying to silence the "closing dbh with active handles..."
> wa
Opss. Code with numbers looks like this:
$sth->execute;
my ($val) = $sth->fetchrow_array;
#[1] my ($val2) = $sth->fetchrow_array;
#[2] $sth->finish;
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mail
I have never been in this situation (32/64 bit) and i don't have
red-hat for test it.
I don't know how to help you.
On Jan 26, 2008 6:28 AM, Jim Dodgen <[EMAIL PROTECTED]> wrote:
> thanks for all the help, I think I am getting closer ... but still
> broken ... look for the "---" for my comments
>
thanks for all the help, I think I am getting closer ... but still
broken ... look for the "---" for my comments
--- tail of the install of sqlite 3.5.4
--
/usr/bin/install -c -d /usr/local/bin
./libtool --mode=install /usr/bin
On Fri, 2008-01-25 at 15:04 -0800, Jim Dodgen wrote:
> you are correct. sorry to offend
No offense taken, dude. :) I'm usually lurking in here only, anyway.
Also, I wasn't too serious...
What I *did* mean though, is, to tell you (and a lot of other readers,
for that matter) about the difference
if you DBD::SQlite built statically, then it uses it's internal SQLite
If it's linked again libsqlite, you can check it by command ldd on:
# find /usr/lib/perl5/ -name 'SQLite.so'
/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/DBD/SQLite/SQLite.so
# ldd /usr/lib/perl5/site_perl/5.8.8/i686-linux/au
you are correct. sorry to offend
Karsten Bräckelmann wrote:
On Thu, 2008-01-24 at 19:41 -0800, Jim Dodgen wrote:
sorry I attached another email by accident, it's content is not related
to my question
No, you pretty much did so on purpose.
You *replied* to a previous post, which inher
thanks for the education, looks like i have multiple versions floating
around, as seen below I'll blow a way the lib64 version just to
eliminate the confusion.
How do I tell which one is being used?
computer A (this has 3.5.4 installed)
lrwxrwxrwx 1 rootroot 19 Feb 8 2006 /usr/lib64/l
On Thu, 2008-01-24 at 19:41 -0800, Jim Dodgen wrote:
> sorry I attached another email by accident, it's content is not related
> to my question
No, you pretty much did so on purpose.
You *replied* to a previous post, which inherits special headers for
threading. Instead, you should have wrote a
On 1/25/08, Alexander Batyrshin <[EMAIL PROTECTED]> wrote:
> I have no problem with 3.5.4.
> Maybe your DBD::SQLite is linked with libsqlite in other dirrectory?
> For example your DBD::SQLite is linked against
> /usr/lib/libsqlite3.so.0, and you installed new 3.5.2 into
> /usr/local/lib ?
I've ju
There is two way of compiling DBD::SQLite:
1. to use his own internal version of SQLite
USE_LOCAL_SQLITE=1 perl Maker.pl
2. to use shared library of SQLite
SQLITE_LOCATION=/path/to/libsqlite perl Makefile.pl
So if you install 3.5.4 in /usr/local/lib, you should set
SQLITE_LOCATION=/usr/local/lib/
I have tend to build the DBD::SQLite from source, when ever I have built
with it looking for sqlite libs it reports a old version older than
3.3.9 or something
and then uses the current 3.4.2 stuff supplied in the module.
I do have 3.5.4 installed, it migh be that there could be a older
versio
I have no problem with 3.5.4.
Maybe your DBD::SQLite is linked with libsqlite in other dirrectory?
For example your DBD::SQLite is linked against
/usr/lib/libsqlite3.so.0, and you installed new 3.5.2 into
/usr/local/lib ?
Here is my linking information:
# ldd /usr/lib/perl5/site_perl/5.8.8/i686-l
sorry I attached another email by accident, it's content is not related
to my question
Jim
Jim Dodgen wrote:
the latest DBD::SQLite (a Perl module) was buit with 3.4.2 I have
attempted to get a version up to 3.5.2 with no success so far.
anyone have any success yet? If so what is the magi
On Thu, May 10, 2007 at 08:04:51 -0500, P Kishor wrote:
> are there any guidelines on how to hook a new SQLite lib with the
> DBD package since the CPAN version seems to be running a few
> versions late.
No special actions needed, default build of DBD::SQLite will use
pre-installed shared library
lt;[EMAIL PROTECTED]>
To: sqlite-users@sqlite.org
Sent: Tuesday, April 4, 2006 4:18:35 PM
Subject: Re: [sqlite] DBD Sqlite
On 4/4/06, Nathan Kurz <[EMAIL PROTECTED]> wrote:
>
> > >> 3. The performance for inserts is really bad. Around 40k entries
> takes a
>
Sripathi Raj wrote:
I don't begin the transaction with begin. My assumption was that the first
insert operation would automatically begin a transaction.
It does. But, the transaction it starts ends with that insert, and a new
transaction begins with the next insert.
You need an explicit
On 4/4/06, Nathan Kurz <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 04, 2006 at 04:18:35PM -0700, Sripathi Raj wrote:
> > On 4/4/06, Nathan Kurz <[EMAIL PROTECTED]> wrote:
> > >
> > > > >> 3. The performance for inserts is really bad. Around 40k entries
> > > takes a
> > > > >>few hours.
On Tue, Apr 04, 2006 at 04:18:35PM -0700, Sripathi Raj wrote:
> On 4/4/06, Nathan Kurz <[EMAIL PROTECTED]> wrote:
> >
> > > >> 3. The performance for inserts is really bad. Around 40k entries
> > takes a
> > > >>few hours. What might I be doing wrong? I do a commit after
> > > >>all
On 4/4/06, Nathan Kurz <[EMAIL PROTECTED]> wrote:
>
> > >> 3. The performance for inserts is really bad. Around 40k entries
> takes a
> > >>few hours. What might I be doing wrong? I do a commit after
> > >>all the inserts.
> > >
> > > A few things to help with speed:
> > >
> > > 1. Use DBI'
> >> 3. The performance for inserts is really bad. Around 40k entries takes a
> >>few hours. What might I be doing wrong? I do a commit after
> >>all the inserts.
> >
> > A few things to help with speed:
> >
> > 1. Use DBI's prepared statements; eg, 1 prepare() and many execute().
>
> Yes
Darren Duncan wrote:
> At 15:03 -0700 4/4/06, Sripathi Raj wrote:
>> Hi,
>> I have a few questions regarding SQLite. I'm using it on Windows and
>> connecting to it from Perl.
>
> And I will answer some of them.
>
>> 1. How do I find out if the current version of DBD::SQLite uses SQLite
>> 3.0or gr
At 15:03 -0700 4/4/06, Sripathi Raj wrote:
Hi,
I have a few questions regarding SQLite. I'm using it on Windows and
connecting to it from Perl.
And I will answer some of them.
1. How do I find out if the current version of DBD::SQLite uses SQLite
3.0or greater?
DBD::SQLite versions >= 1.0
$sql = "SELECT varint FROM mytable";
$sth = $dbh->prepare($sql);
eval { $sth->execute(); };
if ($@) {
print STDERR "[EMAIL PROTECTED]";
exit(1);
}
my $ary_ref = $sth->fetchrow_arrayref;
print STDERR "RETURN IS $ary_ref->[0] \n";
__END__
bash-3.00$
f;
print STDERR "RETURN IS $ary_ref->[0] \n";
__END__
bash-3.00$ rm /tmp/stest.db
bash-3.00$ ./tst.pl
RETURN IS 01237
-Original Message-----
From: Cyril Scetbon [mailto:[EMAIL PROTECTED]
Sent: Friday, March 17, 2006 11:04 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DBD
ers wherever possible.
-Clark
- Original Message
From: Cyril Scetbon <[EMAIL PROTECTED]>
To: sqlite-users@sqlite.org
Sent: Thursday, March 16, 2006 11:15:30 PM
Subject: Re: [sqlite] DBD::SQLite
just a $dbh->do("insert into mytable(varint) values ('01234')";
It&#x
al Message-
From: Cyril Scetbon [mailto:[EMAIL PROTECTED]
Sent: Friday, March 17, 2006 1:16 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DBD::SQLite
just a $dbh->do("insert into mytable(varint) values ('01234')";
It's not working correctly with SQLite but no pr
Can you run .schema on the table?
-Original Message-
From: Cyril Scetbon [mailto:[EMAIL PROTECTED]
Sent: Friday, March 17, 2006 1:16 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] DBD::SQLite
just a $dbh->do("insert into mytable(varint) values ('01234')&q
just a $dbh->do("insert into mytable(varint) values ('01234')";
It's not working correctly with SQLite but no problem with Oracle.
Chris Werner a écrit :
Can you give a code example? I have just tried, and can load string values
with a leading 0 and m/^\d+$/
I suspect the problem is in your tr
Can you give a code example? I have just tried, and can load string values
with a leading 0 and m/^\d+$/
I suspect the problem is in your treatment of perl...
Christian Werner
-Original Message-
From: Cyril Scetbon [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 16, 2006 2:56 PM
To: sqli
Title: RE: [sqlite] DBD::SQLite SQLite Ver 3.2.7
Steve, Jarl,
Thanks for the replies. Eric thanks for the info. So this needs to be a patch in the DBD-SQLite-1.11 module? Something like the attached patch I assume?
Matt Seargeant,
How do we get this into the CPAN archives?
Thank you
Eric Bohlman earlier wrote this:
--
You'll need to go into dbdimp.c and change the two calls to
sqlite3_prepare() so that the third argument is -1 rather than
zero. This is due to the change in check-in 3047.
--
In order to get this to work, modify DBD::SQLite dbdimp.c so that the 3rd
parameter of each call to sqlite3_prepare() is -1 instead of 0.
Steve
Chris Werner wrote:
Hello,
The current release of SQLite, 3.3.4 does not seem to be compatible with the
perl DBD driver. The embedded SQLite package
On 28 Jan 2006, at 01:09, Randy J. Ray wrote:
Although - now that I've said all that - does the dbd interface
actually use sqlite3, or just version 2?
DBD::SQLite uses sqlite3.
Correct.
There's DBD::SQLite2 for those who have to use
sqlite2 for legacy purposes, but I'm pretty sure it isn'
> Although - now that I've said all that - does the dbd interface
> actually use sqlite3, or just version 2?
DBD::SQLite uses sqlite3. There's DBD::SQLite2 for those who have to use
sqlite2 for legacy purposes, but I'm pretty sure it isn't being maintained.
Randy
--
Maybe the perl interface always binds variables as strings. This
won't work - just like the second "SELECT count(*)" query below
didn't work as one might expect.
SQLite version 3.3.0
Enter ".help" for instructions
sqlite> create table ab(a,b);
sqlite> insert into ab values(1, 2);
sqlite> select c
Clark Christensen wrote:
What's not clear is whether the limitation is with SQLite, DBI, or DBD-SQLite,
or whether later revisions of any has enabled placeholders at that level.
Does sqlite3_prepare/step work with placeholders in the HAVING expression?
Clark,
The syntax description for the
For what it's worth, I confirm that:
select tech_id, acct_number from tech_master group by acct_number having
count(*) > 20;
returns 40 rows (the table has nearly 10K rows) from the SQLite shell. Same
for Perl as
$sql = "select tech_id, acct_number from tech_master group by acct_number
havin
On 28 Apr 2005, at 17:53, Clark Christensen wrote:
For what it's worth, it looks like getsqlite.pl hasn't been
updated in quite some time. It gets the package just fine,
but it extracts the archive using the archive's embedded
dirnames, then changes directory to 'sqlite', at which
point, the rest
--- Darren Duncan <[EMAIL PROTECTED]> wrote:
> At 6:20 PM -0700 4/27/05, Clark Christensen wrote:
> >Being new to compilers, I have a question about building
> >DBD-SQLite (for Perl). If I want to update the
> underlying
> >SQLite code in DBD-SQLite to the current release,
> (v3.2.1),
> >i sit si
At 6:20 PM -0700 4/27/05, Clark Christensen wrote:
Being new to compilers, I have a question about building
DBD-SQLite (for Perl). If I want to update the underlying
SQLite code in DBD-SQLite to the current release, (v3.2.1),
i sit simply a matter of putting the current SQLite sources
into the DBD
Sorry.. I actually had a typo in that sample, but even with it fixed I
get the same results (just runs slower). New code with fixed typo:
#!/usr/bin/perl -w
use strict;
use DBI;
my ( $query, $table_name, $sth, $sth2, $dbh, $dbh2, @rows, @rows2,
$count ); my $database_name = "/home/brad/test.db";
On 31 Dec 2003, at 12:33, David Morel wrote:
$dbh = DBI->connect("DBI:SQLite:/var/db/INSPIRON.primaire.sql");
$dbh->do( "ATTACH '/var/db/INSPIRON.secondaire.sql' AS secondaire ;" );
of course, the very same command succeed when typed in sqlite
Is this a bug or am I doing something wrong ?
Possibl
On 26 Nov 2003, at 16:57, [EMAIL PROTECTED] wrote:
I can't vacuum database from script. I get following error:
DBD::SQLite::db do failed: SQL logic error or missing database at
E:\sql.pl
I have a feeling this is due to this in the sqlite docs: "[VACUUM] This
command will fail if there is an acti
67 matches
Mail list logo
