Re: [sqlite] parameters in a view, disallowed? (docs issue)

On 12/20/2012 4:10 PM, Larry Brasfield wrote: > Igor Tandetnik wrote: [regarding where parameters allowed, "where literals are"] >> > >> > How did you discern this? >> >> I know from experience where parameters work (SELECT, INSERT and >> similar; also ATTACH as one of my projects happens to

Re: [sqlite] How to verify referential integrity of SQLite database

On Thu, Dec 20, 2012 at 3:05 PM, Levi Haskell (BLOOMBERG/ 731 LEXIN) < lhask...@bloomberg.net> wrote: > Tested, works perfectly. Thanks! > > Two questions/observation: > > 1. Should there be a way to determine the parent key w/o looking at or > parsing the schema DDL commands? > > For example: >

Re: [sqlite] Updating database views ( instead of triggers ) using typed datasets and system.data.sqlite

Thank you guys very much for answering, Igor, i belive you are right. I think it is a typed dataset .NET bug. There exists an option to use optimistic concurency. If it's on then it uses rows affected to check if row was modified or not. The stupidity of it is even if it is turned off ( checkbox

Re: [sqlite] Updating database views ( instead of triggers ) using typed datasets and system.data.sqlite

On 12/20/2012 7:21 PM, BareFeetWare wrote: The changes are in fact made, but those avenues for checking don't work. I'm tempted to label this as a bug in SQLite, since I see no reason for the limitation. If the trigger changes 20 records across 5 tables, which results in 63 rows in the view

Re: [sqlite] Updating database views ( instead of triggers ) using typed datasets and system.data.sqlite

> *Throws DBconcurrency violation. Affected rows 0 instead of 1.* I use updatable views all the time, via "instead of" triggers, as you described. They work well. I think your problem may be that SQLite doesn't acknowledge changes via the changes() SQL function and sqlite3_changes() C

[sqlite] Updating database views ( instead of triggers ) using typed datasets and system.data.sqlite

Hello, I am developing an application using Visual Studio 2008 ( C# .NET 3.5SP1 ) and sqlite ( System.Data.Sqlite ). Whole database interaction is written using strongly typed datasets. All was fine while working with tables, but when i tried to update views, it was brick wall. I was hoping to

Re: [sqlite] parameters in a view, disallowed?

On 12/20/2012 5:20 PM, Simon Slavin wrote: I've understood that the optimizer can be usefully used on prepared statements before the parameters are known. An implication from this is that table names cannot be parameterized. Table names cannot be parameterized for the simple reason that,

Re: [sqlite] parameters in a view, disallowed?

On 20 Dec 2012, at 8:26pm, Igor Tandetnik wrote: > I know from experience where parameters work (SELECT, INSERT and similar; > also ATTACH as one of my projects happens to use it this way), and where they > don't (all forms of CREATE; I haven't tried ALTER but I'm 99% sure

Re: [sqlite] parameters in a view, disallowed? (docs issue)

On 12/20/2012 4:10 PM, Larry Brasfield wrote: Igor Tandetnik wrote: [regarding where parameters allowed, "where literals are"] > > How did you discern this? I know from experience where parameters work (SELECT, INSERT and similar; also ATTACH as one of my projects happens to use it this way),

Re: [sqlite] parameters in a view, disallowed? (docs issue)

Igor Tandetnik wrote: [regarding where parameters allowed, "where literals are"] > > How did you discern this? I know from experience where parameters work (SELECT, INSERT and similar; also ATTACH as one of my projects happens to use it this way), and where they don't (all forms of CREATE; I

Re: [sqlite] parameters in a view, disallowed?

On 12/20/2012 2:30 PM, Larry Brasfield wrote: I believe it's pretty simple. Parameters are allowed everywhere a literal may appear, except in schema definition statements, namely various CREATE statements as well as ALTER TABLE; and also PRAGMA (not sure why). Currently, this leaves SELECT,

Re: [sqlite] How to verify referential integrity of SQLite database

Tested, works perfectly. Thanks! Two questions/observation: 1. Should there be a way to determine the parent key w/o looking at or parsing the schema DDL commands? For example: SQLite version 3.7.16 2012-12-20 01:15:20 Enter ".help" for instructions Enter SQL statements terminated with a

Re: [sqlite] parameters in a view, disallowed?

Igor Tandetnik wrote: On 12/20/2012 1:27 PM, Larry Brasfield wrote: > With recent versions of SQLite, a prepare call fails when there are > parameters in the SQL for a 'create view' statement. Did it ever work with any version of SQLite? Parameters in DDL statements don't make sense. Agreed

Re: [sqlite] parameters in a view, disallowed?

On 12/20/2012 1:27 PM, Larry Brasfield wrote: With recent versions of SQLite, a prepare call fails when there are parameters in the SQL for a 'create view' statement. Did it ever work with any version of SQLite? Parameters in DDL statements don't make sense. I stumbled into this for two

[sqlite] parameters in a view, disallowed?

With recent versions of SQLite, a prepare call fails when there are parameters in the SQL for a 'create view' statement. I stumbled into this for two reasons: The documentation for parameters and ..._prepare does not contra-indicate such usage; it seemed perfectly sensible; and it was useful

Re: [sqlite] SQLite Version 3.7.15.1

On 12/20/2012 01:26 PM, Patrik Nilsson wrote: Thank you for the release! I can't find sqlite-shell-linux-x86-3071501.zip and sqlite-doc-3071501.zip. Thanks. They are there now. ___ sqlite-users mailing list sqlite-users@sqlite.org