On Thu, 23 Sep 2004, Alex wrote:
>> If I have time at the weekend, I might have a bash at producing a patch
>> that will implement what is required. No promises, mind.
>>
>> What would be preferred? Convert the trigger to an update trigger, or fire
>> a delete trigger followed by an insert trigger?
>>
>> I'd prefer the former (update) as requested in the ticket. I think it may
>> be easier to code, as well, but not sure.
>
>Yes, I agree, firing the UPDATE trigger would be better. But I would also be
>satisfied with an additional DELETE trigger call. BTW, if you release this
>patch, which SQLite version will it be available for? Only 3.x or also 2.x?
I'd probably initially do it for 3.x, as 2.x is basically in feature
freeze, I believe. Are you 2.x based?
BTW, anyone else have an opinion on whether it should be a update trigger
or delete + insert?
>
>> What is stopping you checking for an existing row in the trigger body
>> yourself? Something like (based on your example):
>> create trigger table_replace_check
>> before insert on 'table'
>> for each row
>> begin
>> insert into table_log
>> select 'D', id, SecDbKey from 'table'
>> where id=NEW.id;
>> end;
>>
>> Then you just keep a regular post insert trigger to put the new updated
>> values into the log.
>
>The example I posted is a simple case I use for testing. Other people will
>create different tables with differend fields, and I have no idea how these
>tables will look like. So, how can I code a trigger for an arbitrary table
>without doing havy parsing of the incoming "CREATE TABLE" query? No, firing
>the UPDATE trigger is definitely a better solution :)
So, you're expected to provide a SQL front end to a legacy database,
without dumping the old database, and keep the two in sync, but allow
people to create arbitrary tables in the SQL frontend that will be synced
to the legacy backend?
Don't want much, do they:)
>
>Regards,
>Alex
>
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
