]
> [mailto:[EMAIL 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 t
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 in
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 s
[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
>> a
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 t
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 mult
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 ha
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, u
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 con
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
> co
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, i
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 erro
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 to
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 t
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
> )
>
Hi All,
Short question:
What's the best way (or your way) of facilitating an updatable view (a
view that will accept insert, delete and update, propagating changes
back to the underlying tables), especially for columns that are joined
to satisfy normalization?
Long version of question:
Pr
Hi All,
I'm using triggers to make my views updatable (ie the user can edit
the values view because SQLite will instead change the related source
table value). Which method is best to facilitate this?:
1. Use the "instead of update on ViewName" syntax. Trigger on the
update of the view as
19 matches
Mail list logo
