Query Power Users

Query Naming Conventions for 8.9 Conversion


            Our current 8.0 version of the Higher-Ed Oracle/Peoplesoft system (a.k.a., Access.SMU) will be upgraded to a new 8.9 version in June, 2007.  All queries existing in the 8.0 system (public and private, regardless of name) as of Feb. 17, 2007 will be transferred automatically to the new 8.9 version.  No action is required on your part.

Any query you created or modified since Feb. 17 that you want to carry over to version 8.9, will require action on your part.

            Keeping track of your changes & additions.  Please be aware that the name of any query you have modified since that date must begin with the characters "U_" or those changes will not be brought over to the new system.  The original query will, of course, exist in the system (since they were brought over on Feb. 17th) but the changes will not.  Also, the name of any new query you have created since that date will not be brought over to the new 8.9 version unless its name begins with the characters "U_".   It is important, therefore, that you ensure any modified or new query begins with "U_".    

Established query naming conventions appear in the table below (and we encourage you to follow them when naming queries), but the only critical convention which will effect the migration of a modified/new query to the new system is the "U_" in positions 01 - 02.

Positions

Contents

Comments/Notes

01 - 02

U_

 

03 - XX

Module/department/school or program identifier, followed by an underscore

Examples:  SR_,  MLS_, SEAS_, etc.

XX - XX

Meaningful name for query

Total query name not to exceed 30 characters.

            Important Notes:   (1) Any modified or new query which does not contain the characters "U_" in the first two positions should be renamed.   (2) If you have a query that is business critical and, therefore, must work when the new system comes up in June, you should coordinate with the module lead for your area to ensure the query is tested during one of our testing "rounds" prior to go-live.  Also, business critical queries should be "public" so that designees can run them whenever the owner/creator of the query is not available.  (3) Any issues you have with queries after go-live in June should be forwarded first to your module lead for triage.