Re: SPL & Triggers - do's and don'ts

Jack Parker wrote: } } > } > Has anyone got a useful do's and don'ts guide to developing SPL/triggers? } > } > I am involved in a project that is making extensive use of SPL (I } > am pretty sure that this is a don't all by itself!) and am concerned } > about possible performance considerations due to parameter passing, } > cache, nested calls etc. We are running Online 7.2 on HP UX 10. } > } > We have invested in Informix training courses, read the manuals and } > bought the only book on the market place about this subject - any } > suggestions based on development experience would be much appreciated. } > } > Slanje, } > Glyn } > } } Check out Micheal Gonsalezs' book on SPLs. Prentice Hall (Informix press) } is putting it out. I have no idea what the title or ISBN number is - } Micheal was working on it last year and it should be cooked by now. } Micheal is sort of the groups unofficial SPL guru. } } cheers } j. } ________________________________________________________________________ } Jack Parker - Hewlett Packard, DMD/IS Boise, Idaho, USA } jparker@boi.hp.com Currently on loan to PLD/PE } ________________________________________________________________________ } Outside of a dog a book is a man's best friend. } Inside of a dog it's too dark to read. (Groucho Marx) } ________________________________________________________________________ } Any opinions expressed herein are my own and not those of my employers. } ________________________________________________________________________ Title: Informix Stored Procedures Programming ISBN: 0-13-206723-4 We are starting to use stored procedures extensively with a minimum of logic at the client application (e.g.4GL, etc.) as the SP can cut way down on the network traffic if you bundle logically related-SQL in the stored procedure. One problem encountered was that temp tables, created by a client 4GL program, are not visible to any stored procedures executed on a remote server via the syntax EXECUTE PROC database@sitename:my_spl. Interestly, changing databases but not servers still affords visibility to the temp tables. Seems a bit logically inconsistent. I assume it has something to do with temp dbspaces. -- Carol Davies cdavies@csc.com