For SQLite is there an easy way to find out ALL other tables, queries and
triggers that will be affected when performing a change to a particular
column under the cursor? That would make refactoring so much easier.
___
sqlite-users mailing list
sqlite-use
On Tue, Oct 8, 2013 at 9:58 PM, Petite Abeille wrote:
>
> On Oct 8, 2013, at 8:10 PM, Stephan Beal wrote:
>
> > (link to the original post not included because the archives are only
> > visible to list members):
>
> Hmm?
>
> http://news.gmane.org/gmane.comp.version-control.fossil-scm.user
Sorry
On Oct 8, 2013, at 8:10 PM, Stephan Beal wrote:
> (link to the original post not included because the archives are only
> visible to list members):
Hmm?
http://news.gmane.org/gmane.comp.version-control.fossil-scm.user
___
sqlite-users mailing list
s
On Tue, Oct 8, 2013 at 8:01 PM, Dan Kennedy wrote:
> On 10/08/2013 07:39 PM, Clemens Ladisch wrote:
>
>> Paul Harris wrote:
>>
>>> Many years ago, Igor mentioned that you should always reset/finalize any
>>> prepared statements before calling COMMIT.
>>>
>>> I am wondering, is this still true?
>>
On 10/08/2013 07:39 PM, Clemens Ladisch wrote:
Paul Harris wrote:
Many years ago, Igor mentioned that you should always reset/finalize any
prepared statements before calling COMMIT.
I am wondering, is this still true?
Yes.
Do I have to reset before I commit? And where is the requirement wri
When a SQL parsing error happens, the message returned by sqlite3_errmsg() is
pretty terse... is there some way to retrieve more context, so that the user
has more than one token to help locate the problem?
For example, having the previous several tokens that were successfully parsed
would give
Hello all,
Version 0.3 of the SQLite undelete/recovery tool has been
released, still very much in beta phase, no doubt a lot of bugs
and core dumps on some files.
http://pldaniels.com/undark/undark-0.3.tar.gz
(MD5SUM:19d3183e7a0b782d658bcb631cc4146b )
Reg
Paul Harris wrote:
> Many years ago, Igor mentioned that you should always reset/finalize any
> prepared statements before calling COMMIT.
>
> I am wondering, is this still true?
Yes.
There was a change in 3.7.11, but not with COMMIT itself:
| * Pending statements no longer block ROLLBACK. Instea
Hello all,
Many years ago, Igor mentioned that you should always reset/finalize any
prepared statements before calling COMMIT.
I am wondering, is this still true?
I have prepared SELECTs and INSERTs which have been step()'d, but not reset.
the SELECTs tend to be stepped until there is no more da
Kurt, Keith
Thanks very much for your help.
It's very much appreciated.
Best Regards
Dean
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
JKL, Igor, Tom
Thank you very much for the advice.
It's very much appreciated and helps A LOT!
Best Regards
Dean
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
11 matches
Mail list logo