On 15 Jul 2004, at 21:03, D. Richard Hipp wrote:
Matt Sergeant wrote:
In sqlite3, I can't get sqlite3_changes working for DELETE. I notice
there's no tests for this. (I'm talking "DELETE FROM T WHERE ..."
rather than flat out DELETE all).
Can anyone else confirm this?
There is at least one
Matt Sergeant <[EMAIL PROTECTED]> writes:
> On Thu, 15 Jul 2004, Randy J. Ray wrote:
>
>> > (now I just have to work out a release/migration strategy - since a raw
>> > CPAN install will break people's apps).
>>
>> I would suggest renaming it to DBD::SQLite3, since the underlying library
>>
On 15 Jul 2004, Hans-Juergen Taenzer wrote:
> Matt Sergeant ([EMAIL PROTECTED]) wrote:
>
> > This is now the only thing holding back DBD::SQLite's port to
> > sqlite3. I've got everything else working and it's all looking
> > great. inserts are about the same speed as sqlite2, but selects
>
(now I just have to work out a release/migration strategy - since a raw
CPAN install will break people's apps).
I would suggest renaming it to DBD::SQLite3, since the underlying library
itself looks to be embedding "3" into most (if not all) API hooks anyway.
Are there any plans to have the
Matt Sergeant wrote:
In sqlite3, I can't get sqlite3_changes working for DELETE. I notice
there's no tests for this. (I'm talking "DELETE FROM T WHERE ..." rather
than flat out DELETE all).
Can anyone else confirm this?
There is at least one existing test for this (laststmtchanges-1.5).
I've
Matt Sergeant ([EMAIL PROTECTED]) wrote:
> This is now the only thing holding back DBD::SQLite's port to
> sqlite3. I've got everything else working and it's all looking
> great. inserts are about the same speed as sqlite2, but selects
> have sped up about 30%.
That's not my experience.
6 matches
Mail list logo