L PROTECTED] Behalf Of Dennis Cote
> Sent: Tuesday, February 12, 2008 9:41 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Updatable views
>
>
> John Stanton wrote:
> > That ia a nice idea. To have a pragma which specied the
> dialect. Th
John Stanton wrote:
> That ia a nice idea. To have a pragma which specied the dialect. There
> could be "strict" or "ansi" and "mysql", "oracle", "sqlserver" etc etc.
> It would give tighter control over hard to track annoying minor syntax
> errors.
>
I don't think we need anything that
BareFeet wrote:
>
> I thought I saw syntax of some other SQL engines that
> permit if/then or case/when type branching within a trigger, but I may
> be mistaken.
>
A case/when expression is just that an expression. It can appear any
where an expression can be used. It can contain multiple
[EMAIL PROTECTED] wrote:
> John Stanton <[EMAIL PROTECTED]> wrote:
>> That ia a nice idea. To have a pragma which specied the dialect. There
>> could be "strict" or "ansi" and "mysql", "oracle", "sqlserver" etc etc.
>> It would give tighter control over hard to track annoying minor syntax
Hi Dennis,
> I don't think there is any way in SQL to eliminate the redundant
> lookups.
OK, thanks. I thought I saw syntax of some other SQL engines that
permit if/then or case/when type branching within a trigger, but I may
be mistaken.
>> where new.Amount not null
>>
On 2/11/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> John Stanton <[EMAIL PROTECTED]> wrote:
> > That ia a nice idea. To have a pragma which specied the dialect. There
> > could be "strict" or "ansi" and "mysql", "oracle", "sqlserver" etc etc.
> > It would give tighter control over hard
John Stanton <[EMAIL PROTECTED]> wrote:
> That ia a nice idea. To have a pragma which specied the dialect. There
> could be "strict" or "ansi" and "mysql", "oracle", "sqlserver" etc etc.
> It would give tighter control over hard to track annoying minor syntax
> errors.
>
And, it would
That ia a nice idea. To have a pragma which specied the dialect. There
could be "strict" or "ansi" and "mysql", "oracle", "sqlserver" etc etc.
It would give tighter control over hard to track annoying minor syntax
errors.
Dennis Cote wrote:
> BareFeet wrote:
>> No, I have no MS legacy or
BareFeet wrote:
> Hi All (especially Dennis I guess ;-) )
>
> Focusing on the "instead of update" trigger in my example (copied
> below), you'll notice that the trigger scans through the table [Orders
> Refunds Amount] three times to find the matching ID, once for each of
> insert, delete,
Hi All (especially Dennis I guess ;-) )
Focusing on the "instead of update" trigger in my example (copied
below), you'll notice that the trigger scans through the table [Orders
Refunds Amount] three times to find the matching ID, once for each of
insert, delete, update, whose where tests
BareFeet wrote:
>
>> Since you can't use a create table statement in a trigger,
>
> Yes, I thought of doing that and realized the limitation of triggers
> not allowing create temporary table. Is this restriction part of
> standard SQL, or just SQLite? Is it likely to change? It seems a
>
Hi Stephen,
> I should note that there's a gross inefficiency when using triggers
> to handle updates or deletes against views; SQLite does the
> equivalent of this:
>
> For UPDATE ... WHERE , SQLite copies the entire
> source view into the temp table.
>
> SELECT * INTO FROM
>
> Then,
BareFeet wrote:
>
> No, I have no MS legacy or habits. I use the
> square brackets for identifiers because I find that using double
> quotes doesn't catch errors. If I say select "column name that does
> not exist" I get a string back. But if I use square brackets SQLite
> gives me an
Hi Dennis,
Thanks for your reply. I really appreciate the feedback.
> This is a very nice set of triggers to handle the base tables of a
> view
> I believe this is the best way to handle this.
Thanks, it's good to at least know that I'm heading the right way.
I believe this is the best way
Stephen Oberholtzer wrote:
> I should note that there's a gross inefficiency when using triggers to
> handle updates or deletes against views; SQLite does the equivalent of
> this:
>
> For UPDATE ... WHERE , SQLite copies the entire
> source view into the temp table.
>
> SELECT * INTO FROM
I should note that there's a gross inefficiency when using triggers to
handle updates or deletes against views; SQLite does the equivalent of
this:
For UPDATE ... WHERE , SQLite copies the entire
source view into the temp table.
SELECT * INTO FROM
Then, it iterates over , looking for rows
BareFeet wrote:
> create trigger [Insert Orders Refunds Joined]
> instead of insert
> on [Orders Refunds Joined]
> for each row
> begin
> insert into [Orders Refunds]
> (
> ID
> , [Order ID]
> , Date
> , Reason
> )
>
17 matches
Mail list logo
