> If you get the time and energy, would love to hear your reasons (or
> at least the top 10) ...


Well - you already hit number one reason on the head "time and energy".  At present (given the number of databases that we work with) there just isn't the time to properly plan out a stored procedure approach.

2nd reason (which heavily influences the first) is that we dont have any significant reason to (because we have a small team that communicates well we have no driving need to control our environment with stored procedures).

3rd reason is that most of what we do with our databases is "read only" so most of what we do are SELECT statements and I have a personal opinion that using SP's for SELECT statements is overkill (we use views instead if we want to restrict access to tables or columns).

4th reason is that we do encapsulate our database interactivity at a CFC level already (so even if the team does grow, DB interaction is managed at central points).  This does put us in a good position if we ever do see the need for SP's.

5th reason is that there is nothing we can identify at this point in time that would benefit from a performance gain by calling SP's in CFMX.

6th reason is that SP's are not portable (and while we have currently standardised on SQL*Server there is no reason to think that this may not change at some point in the future).

(no more time and energy to think of any other reasons)

Having said that, we DO use stored procedures - but only on the DB side for doing background processing (such as creating summary tables from multi-joins or unions, etc.).  We don't call them from CFMX.  That way, we limit SP usage to the database platform itself in case of any need to migrate to a different DB platform.


Gary Menzel
Web Development Manager
IT Operations Brisbane -+- ABN AMRO Morgans Limited
Level 29, 123 Eagle Street BRISBANE QLD 4000
PH: 07 333 44 828  FX:  07 3834 0828



To unsubscribe from this email please forward this email to: [EMAIL PROTECTED]

If this communication is not intended for you and you are not an authorised recipient of this email you are prohibited by law from dealing with or relying on the email or any file attachments. This prohibition includes reading, printing, copying, re-transmitting, disseminating, storing or in any other way dealing or acting in reliance on the information. If you have received this email in error, we request you contact ABN AMRO Morgans Limited immediately by returning the email to [EMAIL PROTECTED] and destroy the original. We will refund any reasonable costs associated with notifying ABN AMRO Morgans. This email is confidential and may contain privileged client information. ABN AMRO Morgans has taken reasonable steps to ensure the accuracy and integrity of all its communications, including electronic communications, but accepts no liability for materials transmitted. Materials may also be transmitted without the knowledge of ABN AMRO Morgans. ABN AMRO Morgans Limited its directors and employees do not accept liability for the results of any actions taken or not on the basis of the information in this report. ABN AMRO Morgans Limited and its associates hold or may hold securities in the companies/trusts mentioned herein. Any recommendation is made on the basis of our research of the investment and may not suit the specific requirements of clients. Assessments of suitability to an individuals portfolio can only be made after an examination of the particular clients investments, financial circumstances and requirements.
ABN AMRO Morgans Limited (ABN 49 010 669 726 AFSL 235410) A Participant of ASX Group
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/

Reply via email to