Subject | Re: [ib-support] Re: Simple challenge |
---|---|
Author | IB/FB List |
Post date | 2002-10-31T19:28:20Z |
Ann,
About triggers:
In MS-SQL when you do not have triggers, the length of varchar fields does
not change and a bunch of others pre-requisites MS-SQL does an "in-place"
update wich is far faster than the other option "deferred update" (i think).
When you have triggers MS-Sql have to create another record "version" to
have "old" and "new" values.
MS Books emphatizes to use every where you can in-place updates, because it
is the cheapiest option.
Does FB have some performance degration when use triggers ?
Of course that is not a simple answer, if the trigger's logic is complex,
runs stored procs, etc, certainly will have performance decrease, but MGA
always create records versions, does triggers cause
any other penalties in updates ?
Having a trigger in the table does not make the process a little slow, wich
is not a good choice for the presented problem, as the goal is to go as
fast as you can ?
see you !
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
At 10:49 31/10/2002 -0500, you wrote:
About triggers:
In MS-SQL when you do not have triggers, the length of varchar fields does
not change and a bunch of others pre-requisites MS-SQL does an "in-place"
update wich is far faster than the other option "deferred update" (i think).
When you have triggers MS-Sql have to create another record "version" to
have "old" and "new" values.
MS Books emphatizes to use every where you can in-place updates, because it
is the cheapiest option.
Does FB have some performance degration when use triggers ?
Of course that is not a simple answer, if the trigger's logic is complex,
runs stored procs, etc, certainly will have performance decrease, but MGA
always create records versions, does triggers cause
any other penalties in updates ?
Having a trigger in the table does not make the process a little slow, wich
is not a good choice for the presented problem, as the goal is to go as
fast as you can ?
see you !
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
At 10:49 31/10/2002 -0500, you wrote:
>At 02:43 AM 10/31/2002 +0000, clementdoss wrote:
>
> >When I read Ann´s 122 seconds <g> I fell off my chair!!!
> >Is it possible to read a file one row at a time and inset the info
> >using QLI?
>
>
>
>
> >If that´s is possible, I sure no one will beat this one!
> >The only thing here is that I must keep the data in the same format
> >they sent me...
>
>One problem is that 20020228 is not a date format that Firebird
>recognizes. 28.02.2002, sure, or February 28, 2002 or 2/28/02
>or a bunch of other variants. I guess one could write a
>simple ufd that would take an eight digit year first date...
>But even then, you'd need to reference the UDF in the insert
>statement. Louis Kleiman's trigger answer is probably better.
>And, probably, we ought to add the ISO date to the list of
>formats we accept.
>
>As I said, ISQL will do the inserts without using a prepared
>statement in about 8 minutes. If you care, you could write a
>ESQL program that uses prepared statements, turns off auto-undo,
>and reads your input file, doing the translation for YYYYMMDD
>to a plausible date format. That would scream.
>
>
>
>Regards,
>
>Ann
>www.ibphoenix.com
>We have answers.
>
>
>
>
>To unsubscribe from this group, send an email to:
>ib-support-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/