RATCLIFFE

Technical Services Limited

NOTE:

Issue 1. February 2001

Hints, tips, and experience for SAS® users

 

 

 

In this issue:

 

Welcome to the first issue of RTSL's information e-newsletter called NOTE:. If you are actively involved in providing solutions with SAS® software, NOTE: will be an invaluable source of information for you.

 

This will be a monthly e-publication, by free subscription (it is not spam). Details for subscribing (and unsubscribing) are at the bottom of this e-newsletter. Encourage your friends and colleagues to subscribe (but please do not include a message in the body of the email, it will not be seen by a human).

 

The articles in NOTE: will reflect the skills and experience of RTSL, i.e. SAS-based application development projects, and SAS-related infrastructure issues.

 

Please keep me informed of things you would like to see featured in NOTE:. Send correspondence to note.editor@ratcliffe.co.uk.

 

-Andrew Ratcliffe

 

 

Integrity Constraints

New in V7, integrity constraints protect your data sets

 

 

 

 

 

Primary keys and foreign keys are used in relational tables. For instance, the customer table may have customer ID as a primary key, and the orders file might have customer ID as a foreign key

Integrity constraints were introduced with version 7 of SAS® software. In essence, they are rules that define the valid forms of your data. The rules can be defined in a number of ways and will be respected by SAS software whenever there is an attempt to update the data set.

 

You can create five different types of integrity constraint rules:

  • A column can contain only non-null values.

  • A column can contain only values that fall within a specific set, range, or list of values, or that duplicate a value in another column in the same row.

  • A column can contain only values that are unique.

  • A column that is a primary key can contain only values that are unique and that are not missing values.

  • A column that is a foreign key (the child) can contain only values that are present in the associated primary key (the parent) or null values. A column that is a primary key can contain only values that cannot be deleted or changed unless the same deletions or changes have been made in values of the associated foreign key. Values of a foreign key can be set to null, but values cannot be added unless they also exist in the associated primary key. 

 

These integrity constraints are similar to those that have been available in industrial strength databases for many years. They are a useful means of ensuring the integrity of your data (including relational data) without repetitive coding in Base SAS programs (or SCL programs).

 

You can use PROC DATASETS, PROC SQL, or SCL functions to create, update, and remove integrity constraints. To list them, you can use PROC CONTENTS. Here is a simplistic example using PROC DATASETS:

 

data master;

  attrib key length=$8

         data length=8;

  key='a0000001'; data=2; output;

  key='a0000002'; data=4; output;

run;

 

proc datasets lib=work nolist;

  modify master;

    ic create ic1=primary key(key);

    ic create ic2=check(where=(data between 2 and 8));

quit;

 

data updt;

  key='a0000001'; data=999; output;

  key='a0000002'; data=8; output;

run;

 

data master;

  modify master updt;

  by key;

run;

 

The log resulting from the final DATA step will be as follows:

 

data master;

  modify master updt;

  by key;

run;

 

key=a0000001 data=999 FIRST.key=1 LAST.key=1 _ERROR_=1 _IORC_=660130 _N_=1

NOTE: There were 1 observations read from the data set WORK.MASTER.

NOTE: The data set WORK.MASTER has been updated.  There were 1 observations rewritten, 0 observations added and 0 observations deleted.

NOTE: There were 1 rejected updates, 0 rejected adds, and 0 rejected deletes.

NOTE: There were 2 observations read from the data set WORK.UPDT.

 

Why is this useful?

It is important to maintain the integrity of your data. Hitherto this has required repetitive coding of integrity rules in your suite of programs. Now, the integrity rules can be coded in one place. This makes them easy to find and easy to maintain.

 

Go to top...

 

SAS® User Group International (SUGI)

Visit Long Beach, California, and learn more about SAS

I always look forward to attending SUGI each year. Not only does it give me the opportunity to (briefly) visit a new destination in the United States, it is also a terrific opportunity to spend a short week with people who are both knowledgeable and keen about SAS software. The sessions at SUGI seem to get better every year. This year's range will include high-level keynote presentations, workshops, and plenty of hints, tips, and experience.

 

This year's SUGI will be held in Long Beach, California. The opening session will be held on the evening of Sunday April 22nd and the closing session will be on the afternoon of Wednesday April 25th. If you'd like to go, now is a good time to book. You can do it over the web at www.sas.com/sugi26, or send an email to sugi@sas.com to ask for a registration booklet. There's a fifty dollar discount for web bookings and those made before March 9th.

 

Don't hold me to it, but I'm expecting to return to Blighty with plenty of information about the forthcoming version 9 of SAS software. The SAS staff at SUGI typically enjoy telling the attendees about forthcoming releases of SAS software.

 

Go to top...

 

Tools of the Trade - Searching

Find things in your application suite, quickly and reliably

If you are using base SAS programs saved in external text files then you can use standard operating system features of you need to do a global search of your code for something. But if your code is held in SAS catalogs, e.g. SCL and source entries, then you need to find an alternative means of searching.

 

The simplest solution is to use PROC BUILD to write the contents of one or more catalogs to an external text file; then you can use the standard OS tools again. To write the contents of two catalogs to one external text file, use this syntax:

 

proc build c=sashelp.afclass batch;

  print source prtfile='c:\temp\codeListing.txt';

run;

 

proc build c=sashelp.aftools batch;

  print source APPEND prtfile='c:\temp\codeListing.txt';

run;

 

Note the APPEND keyword that I've used in the second invocation. By default, PROC BUILD will over-write the output file if it already exists; the APPEND keyword tells PROC BUILD to add its output to the end of an existing file.

 

But there are more sophisticated tools for doing this job within the SAS development environment. One of these is Qualex's Find2000. Available as a free download (for personal use) from www.qlx.com/find2000, Find2000 performs searches of SAS catalogs, SAS data sets, and external text files. Sadly it is only available for version 8 of SAS software.

 

Why is this useful?

I find that I have an all-too-frequent need to find all occurrences of a text string in my applications. Sometimes the string is a message that needs to be changed a little bit. More often, I want to find all places where a method is used in an application because I want to change its signature (the parameters that it takes) in a non-backwards-compatible way.

 

Go to top...

 

SAS® With Style

Make your programs readable and maintainable

The style of your coding can be almost as important as the actual code itself. Of course, the most important aspect of any program is its ability to perform the task expected of it; but secondary to that is the simplicity with which it can be read and understood by both yourself and other programmers. Coding style covers a range of things including layout, naming, and choice of statements.

 

Many popular elements of style are simply common sense, and others are very much personal preference. But if you work in a development team with a number of members, you will find great benefits to be had by standardising on a common set of style elements. If style makes the code more easily readable, then a standard style makes any team member's code instantly more readable to the other team members; and new team members will get up to speed more quickly if they only have one style to get used to.

 

I don't know of any references for SAS style guides, so I've developed my own. Having first used SAS in 1983, I've had many years in which to develop something good - perhaps even perfect! But that's not how programming styles develop and get used. At each client that I visit, I will generally find existing code with one or more elements of consistent style. In these cases I will make sure that the code that we produce for the client adheres to those same standards (unless I can provide a good justification to the client for changing them).

 

So the style recommendations that I will present in this and future issues of NOTE: will be simply recommendations. They must be interpreted and applied to your particular development team's needs.

 

So, let's start with one common sense style element, and one of my personal preferences.

 

Use comments

Place comments in your code. But make the comments useful instead of stating the obvious.

 

Place a comment block at the top of the program that provides a summary of the program's intended functionality. It is commonly a good idea to document the original author and date, plus the date and author and reason for any modifications to the code.

 

Document sections of the code that are not obvious in their intent. Comments regarding why something was done are typically more useful than those that say what is being done. Usually the latter is obvious, but it's the former that really reveals the hidden secrets.

 

One statement per line

Now this is a contentious one! Place no more than one SAS statement on each editor line. And if you can't fit a long statement on a single line, split it across several.

 

So, as an example, an IF statement should be on one (or more) lines, and its associated conditional code should be on second or subsequent lines. Remember too that DO is a statement. See below:

 

if 1 eq 0 then

  moon = 'cheese';

 

if 1 eq 0 then

do;

  moon = 'cheese';

  clouds = 'marshmallow';

end;

 

Using no more than one statement per line has a number of advantages, including:

  • Easier for the syntax checker to highlight statements with syntax errors

  • Easier to add do-end blocks later if necessary

  • Reduces density of functionality, making the code more readable because it's in smaller chunks

 

Go to top...

 

What is Ratcliffe Technical Services?

A quick overview of where NOTE: comes from

Ratcliffe Technical Services Limited (RTSL) is a small UK-based service company. Through RTSL we provide SAS® consultancy and application development services.

 

RTSL accepts both long- and short-term projects. Through the variety of RTSL's clients and their projects we have built a wealth of experience and knowledge of SAS software.

 

If you think you might like to make use of our services, please call us on +44-1322-525672, or email us at enquiries@ratcliffe.co.uk.

 

Go to top...

 

Advertisements

Useful SAS-related services and products

 

 

 

Miscellany – Joining, leaving, back-issues, and legal bits

 

You can subscribe and unsubscribe by visiting our web site at www.ratcliffe.co.uk. Or, to subscribe just click here and hit the Send button in your email client; and to unsubscribe, just click here and hit the Send button in your email client. Do not include a message in the body of the email, it will not be seen by a human.

 

Back issues are available on our web site at www.ratcliffe.co.uk.

 

Please send comments to note.editor@ratcliffe.co.uk

 

NOTE: © 2001 Ratcliffe Technical Services Limited. All rights reserved.

5 Willow Close, Bexley, Kent, GB-DA5 1QY, England

 

Re-publication by permission only. You may forward copies only if no fee is involved. Please encourage the recipients of the forwarded copy to subscribe and get their own free copy of NOTE:

 

Andrew Ratcliffe is a registered partner of SAS UK. NOTE: is a production solely of RTSL and has no affiliation with SAS.

 

Andrew Ratcliffe is Chairman of VIEWS (the UK's independent SAS user group). NOTE: is a production solely of RTSL and has no affiliation with VIEWS.

 

This edition of NOTE: was sent to 70 subscribers.

 

Go to top...