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
Firstly, I have just released a new Perl DBD::SQLite module, which
fixes a few perl-side bugs and moves us from 3.7.7 to 3.7.9.
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 t
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
I started with DBD::SQLite 1.26_05 and went back as much as
DBD::SQLite 1.21. Kept on getting segfaults. Any further back, and I
got DBD::SQLite 1.14 which bundled FTS2, so that wasn't good as well.
Finally, the amazing Audrey Tang to rescue. I downloaded the classic
DBD::SQLite::Amalgamation 3.6.
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
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 FTS3?
--
Puneet Kishor http://www.punkish.org
Carbon Model h
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";
>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 1577 it is executing this code
$dbh
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
I encountered this problem and solved it, so hopefully this will help
some other poor sod.
Audrey Tang's otherwise most excellent DBD::SQLite::Amalgamation
(bless her for this incredible package) was causing segmentation
faults for me while doing FTS3 searches on a RH ES3 Linux box. The
package ve
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
_
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 bit.
___
sqlite-users ma
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
Sorry, this was mis-addressed. Should have gone to the list...
- Forwarded Message
From: Clark Christensen <[EMAIL PROTECTED]>
To: Alexander Batyrshin <[EMAIL PROTECTED]>
Sent: Monday, February 4, 2008 9:46:49 AM
Subject: Re: [sqlite] DBD::SQLite 1.14 prepare_cached bug?
ba
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
Hello All,
I don't know is it right place to discuss this or not. Sorry If I am
doing something wrong.
Installed sqlite-3.5.4 and DBD::SQLite-1.14
I get problems with this code:
%<
#!/usr/bin/perl -w
use strict;
use DBI;
use Data::Dumper;
use Stora
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
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 magic.
Jim
John Stanton wrote:
Using Apache is the problem. The connections are not persistent so
caching is des
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
has anyone created a DBD::SQLite with the full-text search option
turned on? else, 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.
--
Puneet Kishor http://punkish.eidesis.org/
Nelson Inst. for Env. Studi
I figured it out, i needed to pass a parm to Makefile.Pl to force it to
use the local SQLite source.
Jim Dodgen wrote:
Im having a problem geting the perl DBD working with 3.3.15
I integrated the 3.3.15 source with the perl module and all seemed ok.
all is fine with the command line version
Im having a problem geting the perl DBD working with 3.3.15
I integrated the 3.3.15 source with the perl module and all seemed ok.
all is fine with the command line version (sqlite3) but when I run a perl
script i get this:
--- cut here ---
[EMAIL PROTECTED] perl]# ./sqlite_version.pl
install_d
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
Hi,
I have a few questions regarding SQLite. I'm using it on Windows and
connecting to it from Perl.
1. How do I find out if the current version of DBD::SQLite uses SQLite
3.0or greater?
2. How do I allow dirty reads? I understand that the whole file is locked
for writing but I believe I can do
Hi,
I'm using DBD::SQlite with Perl. How do I know that the execution of a
statement failed because the database was locked? Should I examine the
$DBI::errstr? Does DBI set an error code or something?
Thanks,
Raj
$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
spect 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: sqlite-users@sqlite.org
Subject: [sqlite] DBD::SQLite
Hi,
I use DBD::SQLite for accessing a SQLite database, but
: sqlite-users@sqlite.org
Subject: [sqlite] DBD::SQLite
Hi,
I use DBD::SQLite for accessing a SQLite database, but there's an issue
when I tyr to insert a number starting with a 0. In fact, DBD::SQLite
seems to trim the starting 0 of the number. So, when I insert 0234 in a
table I find 234 in
Hi,
I use DBD::SQLite for accessing a SQLite database, but there's an issue
when I tyr to insert a number starting with a 0. In fact, DBD::SQLite
seems to trim the starting 0 of the number. So, when I insert 0234 in a
table I find 234 instead.
Anyone has encoutered and resolved this bug ?
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
Hello,
The current release of SQLite, 3.3.4 does not seem to be compatible with the
perl DBD driver. The embedded SQLite package works quite well, But I would
like to have the full SQLite package installed [so I can use sqlite3]. I do
not seem to be able to locate the source archives, I would be l
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
Does sqlite3_prepare/step work with placeholders in the HAVING expression?
Thanks!
-Clark
- Original Message
From: David Cantrell <[EMAIL PROTECTED]>
To: sqlite-users@sqlite.org
Sent: Friday, January 27, 2006 6:30:14 AM
Subject: [sqlite] DBD::SQLite bug number 17292 - bounty!
Yes
Yesterday I reported this bug, where placeholders don't work in HAVING
clauses when using the DBD::SQLite module in perl. My lovely employers:
http://www.outcometechnologies.com/
have agreed to pay a bounty to whoever can fix this and have their patch
accepted by the DBD::SQLite maintainer.
The
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
Perhaps a bit off-topic for this list, but...
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-SQL
ion or copying
of this e-mail message is strictly prohibited. If you have received this
message in error, please immediately notify the sender and delete this
e-mail message from your computer.
-Original Message-
From: Brad DerManouelian [mailto:[EMAIL PROTECTED]
Sent: Monday, March 28, 2005
Sorry if this is the wrong forum, but has anyone run into a problem with
leaking file handles when using SQLite with Perl DBI and DBD::SQLite?
I am calling finish() and disconnect() when I'm done with each
connection, but lsof reports my database file opens once for each
connection and never close
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
Hi all,
I get this error when doing an ATTACH with DBD::SQLite:
DBD::SQLite::db do failed: SQL logic error or missing database at
/http_root/test.pl line 7
my test script is this:
#!/usr/bin/perl -w
use DBI;
use DBD::SQLite;
$dbh = DBI->connect("DBI:SQLite:/var/db/INSPIRON.prim
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
Hello sqlite-users
I'm using DBD-SQLite 2.8.6 on WindowsXP SP1 ActiveState Perl 5.8.0.
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
my Perl-script:
use DBI;
my $dbh = 'DBI'->connect('dbi:SQLite:dbname=sq
88 matches
Mail list logo
