Path: utzoo!dciem!nrcaer!sce!cognos!nigelc
From: nigelc@cognos.UUCP (Nigel Campbell)
Newsgroups: comp.databases
Subject: Re: SQL PreCompilers
Message-ID: <8663@cognos.UUCP>
Date: 7 Aug 90 14:53:31 GMT
References: <319.26b9b861@usgcdh.uucp>
Reply-To: nigelc@cognos.UUCP (Nigel Campbell)
Organization: Cognos Inc., Ottawa, Canada
Lines: 39

In article <319.26b9b861@usgcdh.uucp> setas01@usgcdh.uucp writes:
>
> Re : SQL Precompilers

>CA-DB optimizes the query at preprocess time and stores the access
>plans in the database.  At run time, these access plans are executed.
>Of course, CA-DB has to also deal with changes in the database that
>could invalidate an access plan and it does it automatically.
>

Just my 2 cents about using systems that support storing the compile
unit in a db .

If your application is replicated across multiple instances of the
db (as happens in government offices in Canada quite frequently) you
have to remember to migrate the compile units along with your exe files when
updates to programs occur . 

If your process manipulates multiple databases then you would have
several compile units for the exe file not one . This increases the chance
of errors when distributing updates to the application .

Some systems will not store the reopt'd strategy for a compile unit marked
dirty if the transaction is read-only , so where is the gain over not
storing a compile unit ? As you may never know when this has occured you
end up running a batch process that runs around all the databases and use
a DBA tool (if you have it) to reopt the compile unit ready for the next
day .






-- 
Nigel Campbell          Voice: (613) 783-6828                P.O. Box 9707
Cognos Incorporated       FAX: (613) 738-0002                3755 Riverside Dr.
uucp: nigelc@cognos.uucp || uunet!mitel!sce!cognos!nigelc    Ottawa, Ontario
                                                             CANADA  K1G 3Z4