Kevin Benson wrote:
At least, there's this:
http://sqlite.org/docsrc/info/7276f4a4a3e338ea187cb5e50c57e4f9806aed89?sbs=0
+ERROR_MSG {parameters are not allowed in views} {
+ The right-hand side of a CREATE VIEW (that is to say,
+ the SELECT statement that defines the view) may not contain
+
On Fri, Dec 21, 2012 at 12:53 AM, Larry Brasfield wrote:
> 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
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
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,
sy
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 it won't
> work the
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),
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 ha
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, INSER
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
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 in
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 i
Thank you for the quick answer.
On Mon, May 14, 2012 at 4:55 PM, Richard Hipp wrote:
> On Mon, May 14, 2012 at 9:49 AM, Baruch Burstein >wrote:
>
> > Are text parameters bound with sqlite3_bind_text automatically escaped
> and
> > quoted, just escaped, just quoted, or neither?
> >
>
>
> Both.
On Mon, May 14, 2012 at 9:49 AM, Baruch Burstein wrote:
> Are text parameters bound with sqlite3_bind_text automatically escaped and
> quoted, just escaped, just quoted, or neither?
>
Both. And neither.
The content of the parameter is not modified in any way. It is copied
directly into the da
Are text parameters bound with sqlite3_bind_text automatically escaped and
quoted, just escaped, just quoted, or neither?
--
Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots
On Dec 23, 2011, at 2:31 PM, Chris Mets wrote:
> A parameterized view allows me to do that just fine in other SQL engines,
Well, MSSQL sports so-called parameterized views, but that's about it.
> but apparently not SQLite.
If you insist on that approach, you could rewrite your view in term of
Another possibility might be to create a parameters table, say:
CREATE TABLE tabparams (p1,p2,p2,p4,p5);
INSERT INTO tabparams VALUES (null,null,null,null,null);
And when creating the view, access tabparams.p1, tabparams.p2, etc. instead
of variables (with an appropriate join clause). Then, bef
parameter
substitution). Thanks & Best regards, Chris > From: k.n...@zonnet.nl
> To: sqlite-users@sqlite.org
> Date: Fri, 23 Dec 2011 18:03:16 +0100
> Subject: Re: [sqlite] Parameters are not allowed in views
>
> On Fri, 23 Dec 2011 06:31:33 -0700, Chris Mets
> wrote:
>
>
On Fri, 23 Dec 2011 06:31:33 -0700, Chris Mets
wrote:
>
> Thanks for the response. In the solution you propose,
> the view is no longer a parameterized view. I assume
> you suggest putting the select statement with the
> paramterized where clause in the code. In my question,
> I simplified the q
On 23 Dec 2011, at 1:31pm, Chris Mets wrote:
> Thanks for the response. In the solution you propose, the view is no longer
> a parameterized view. I asume you suggest putting the select statement with
> the paramterized where clause in the code. In my question, I simplified the
> query. In re
Subject: Re: [sqlite] Parameters are not allowed in views
>
>
> On Dec 21, 2011, at 11:40 PM, Chris Mets wrote:
>
> > Is this truly a limitation of SQLite or am I doing something wrong?
>
> The later. Simply create your view. Then restrict it.
>
> In other words:
&
Where can I learn more about "restrict it". I'm not familiar with the
syntax for using the question mark. Is there a specific part of the
documentation that explains it and how it works?
Thanks,
dvn
On Wed, Dec 21, 2011 at 5:00 PM, Petite Abeille wrote:
>
> On Dec 21, 2011, at 11:40 PM, Chris
On Dec 21, 2011, at 11:40 PM, Chris Mets wrote:
> Is this truly a limitation of SQLite or am I doing something wrong?
The later. Simply create your view. Then restrict it.
In other words:
create view foo as select bar from baz
select * from foo where bar = ?
_
When I execute the following SQL statement: select * from test2 where f2 =
@param;
it prompts me correctly for a parameter value.
However, when I try to create a view: create view testview as select * from
test2 where f2 = @param;
I receive the following error message: Parameters are not
On 26 Aug 2010, at 8:29pm, Alan Chandler wrote:
> On 26/08/10 17:38, Simon Slavin wrote:
>
>> So someone can check it out. Try it with a VIEW that definitely doesn't
>> exist, or use
>>
>> CREATE VIEW IF NOT EXISTS ...
>>
>
> As far as I can work it out, the statement then prepares OK - but
On 26/08/10 20:29, Alan Chandler wrote:
> On 26/08/10 17:38, Simon Slavin wrote:
>
>> So someone can check it out. Try it with a VIEW that definitely doesn't
>> exist, or use
>>
>> CREATE VIEW IF NOT EXISTS ...
>>
>
> As far as I can work it out, the statement then prepares OK - but seems
> then
On 26/08/10 17:38, Simon Slavin wrote:
> So someone can check it out. Try it with a VIEW that definitely doesn't
> exist, or use
>
> CREATE VIEW IF NOT EXISTS ...
>
As far as I can work it out, the statement then prepares OK - but seems
then to execute as a no op. Since having completed that
On 26 Aug 2010, at 4:59pm, Igor Tandetnik wrote:
> Jay A. Kreibich wrote:
>> On Thu, Aug 26, 2010 at 04:32:11PM +0100, Simon Slavin scratched on the wall:
>>>
>>> On 26 Aug 2010, at 3:36pm, Alan Chandler wrote:
>>>
On 26/08/10 13:38, Simon Slavin wrote:
>>>
>>> So you are trying to creat
On Thu, Aug 26, 2010 at 11:59:03AM -0400, Igor Tandetnik scratched on the wall:
> Jay A. Kreibich wrote:
> >> So you are trying to create a VIEW which does already exist. In that
> >> case, there's no mystery about why you're getting an error message.
> >
> > No, he's trying the *PREPARE* a CR
Jay A. Kreibich wrote:
> On Thu, Aug 26, 2010 at 04:32:11PM +0100, Simon Slavin scratched on the wall:
>>
>> On 26 Aug 2010, at 3:36pm, Alan Chandler wrote:
>>
>>> On 26/08/10 13:38, Simon Slavin wrote:
On 26 Aug 2010, at 12:12pm, Alan Chandler wrote:
> This time it reported
On Thu, Aug 26, 2010 at 04:32:11PM +0100, Simon Slavin scratched on the wall:
>
> On 26 Aug 2010, at 3:36pm, Alan Chandler wrote:
>
> > On 26/08/10 13:38, Simon Slavin wrote:
> >>
> >> On 26 Aug 2010, at 12:12pm, Alan Chandler wrote:
> >>
> >>> This time it reported that the view it would have
>>> I'm sorry to ask this, but can you check for us whether a VIEW by that name
>>> really does exist ? Don't forget, VIEWs get saved in the file, they're not
>>> part of the attachment.
>>
>> Yes it does
>
> So you are trying to create a VIEW which does already exist. In that case,
> there's
On 26 Aug 2010, at 3:36pm, Alan Chandler wrote:
> On 26/08/10 13:38, Simon Slavin wrote:
>>
>> On 26 Aug 2010, at 12:12pm, Alan Chandler wrote:
>>
>>> This time it reported that the view it would have created failed because
>>> the table (view) already existed.
>>
>> I'm sorry to ask this, but
On 26/08/10 13:38, Simon Slavin wrote:
>
> On 26 Aug 2010, at 12:12pm, Alan Chandler wrote:
>
>> This time it reported that the view it would have created failed because
>> the table (view) already existed.
>
> I'm sorry to ask this, but can you check for us whether a VIEW by that name
> really do
On 26/08/10 12:20, Pavel Ivanov wrote:
> Yes, "validation" happens only at the time of execution. So you are
> apparently doing something wrong and you better show your code.
>
easiest is to provide links to a copy. I've added a .txt extension to
all the files to stop them being executed by the
Quoth Simon Slavin , on 2010-08-26 13:38:36 +0100:
> I'm sorry to ask this, but can you check for us whether a VIEW by
> that name really does exist ? Don't forget, VIEWs get saved in the
> file, they're not part of the attachment.
And to add to that: if you want them to merely be attached to the
On 26 Aug 2010, at 12:12pm, Alan Chandler wrote:
> This time it reported that the view it would have created failed because
> the table (view) already existed.
I'm sorry to ask this, but can you check for us whether a VIEW by that name
really does exist ? Don't forget, VIEWs get saved in the
> In my code, I delete the view before attempting to recreate it by
> executing the prepared statement. Isn't that the time to validate
> whether there are semantic problems with the statement?
Yes, "validation" happens only at the time of execution. So you are
apparently doing something wrong an
On 26/08/10 10:22, Alan Chandler wrote:
> I am using PHP PDO to access sqlite and have reached a peculiar error
> situation. Basically its saying I can't have parameters in a CREATE
> VIEW sql statement when I am preparing it.
The plot thickens
I replaced all the parameter placeholders with a qu
I am using PHP PDO to access sqlite and have reached a peculiar error
situation. Basically its saying I can't have parameters in a CREATE
VIEW sql statement when I am preparing it.
I can't find any reference to this restriction or the error message in
the SQLite documentation, so I am wonderin
that'll get you the join you're looking for.
-Clark
- Original Message
From: meerkat
To: sqlite-users@sqlite.org
Sent: Tuesday, March 17, 2009 8:00:42 AM
Subject: [sqlite] parameters
Hello,
I am trying to bind some parameters in a query but I can't do it. I hav
meerkat writes:
>
> Hello,
>
> I am trying to bind some parameters in a query but I can't do it. I have the
> following (JavaScript in html page):
SNIP
>
> I get an empty result set even though I know that the variables produce a
> row (tested in external sql program).
>
> If anyone can sug
Hello,
I am trying to bind some parameters in a query but I can't do it. I have the
following (JavaScript in html page):
var rs = db.execute('SELECT distinct '+
'schedule.schedule_id, ' +
'orders.order_no, '+
'orders.order_no_iteration, '+
'organisation.organisation_name, '+
'str
Hello Alexey,
uh, yes, that is true. But preprocessing the value of
user_id, etc. should insulate you from that sort of things, right?
Unfortunately, the Tclers' Wiki does not give a ready solution for
that. But with
[string map {\; "" \[ "" \] "" $user_id]
you can get rid of most threats, right
This is the Tcl binding, right?
You could replace the variable by its value using [string map]:
db eval [string map [list USER_ID $user_id ...] $sql_statement]
or more directly:
db eval \
"CREATE TABLE view_report_01 AS ...
WHERE u.id = $user_id
..."
Regards,
Arjen
On 2009-02-27
Hello!
On Friday 27 February 2009 18:08:19 you wrote:
> [string map {\; "" \[ "" \] "" $user_id]
>
> you can get rid of most threats, right?
We can do
set param {test' sql with some injection}
puts $param
set param [db onecolumn {select quote($param)}]
puts $param
and get result
test' sql with s
Hello!
On Friday 27 February 2009 17:32:36 Arjen Markus wrote:
> This is the Tcl binding, right?
> You could replace the variable by its value using [string map]:
>
> db eval [string map [list USER_ID $user_id ...] $sql_statement]
>
> or more directly:
>
> db eval \
> "CREATE TABLE view_repor
Hello!
Is there way to careate view such as
db eval {
CREATE TABLE view_report_01 AS
?SELECT s.name ?AS service_name,
? t_l_r.cost AS cost
?FROM work.users ? AS u,
? work.user_contracts ?AS u_c,
? work.user_services ?AS u_s,
? work.services ? AS s,
? telephony.telephony_log_rating AS t_l_r,
? tel
47 matches
Mail list logo
