Is there any way to attach formats to a SAS data file?

[ben12]

Hi everyone. I've done a bit of research about this, but can't find a clear answer, although I suspect that the answer is 'No'. 

We have data files which we occasionally send to clients. These are generally "*.sas7bdat" format.

Most of the data stored in these files rely on formats, which are stored in a separate standard SAS code file (ie. "*.sas" file format). So, when we send our SAS data to clients, we also need to send them a formats file. This also means that the clients must run a DATA step on their end in order to attach the formats to the data when they read it in. 

What I want to know is: is there a way of attaching formats to a data file (e.g. via metadata perhaps?) so that they travel with the file when it is sent? For example, SPSS has this ability. 

I'm pretty sure this isn't possible, but I wanted to ask just to make sure. 

Also, does anyone have any suggestions for 'best practice' when sending data and formats together? Is there a standard or preferred method though which this should be implemented? 

Thank you all for your time. 

[Reeza]

How big are the files? Do they need to be sent in a SAS formats?

I would say one suggestion would be to consider just sending a .sas file which recreates the data set via a program? Then no need to worry about compatibility and it will be fairly small. 

Could probably use PROC FORMAT and CNTLOUT/IN to recreate the formats dynamically and then a data step or sql to create the data. I don't think the code I have on here is robust enough that I'd use it but Tom's in the comments is better. Its on my list of things to do at some point....

[ben12]

Thanks Reeza. 

The files are often quite large, depending on the job. Up to 200K+ records may be sent, in some cases. I appreciate your suggestion but In don't think re-creating the data file via would would be a workable solution in this case. 

[Reeza]

Fair enough, but I will point out that's pretty much what .sql files are and is commonly used in other applications. I agree though, would be nice to have a data format that had this all together for sure. I just usually provided either an SPSS file or both the SAS and Format data set needed with a code to recreate/apply the formats at the client side.

[SASKiwi]

You could use PROC CPORT to port both the SAS dataset(s) and the format catalog all in the one SAS transport file. All your client needs to do then is to use PROC CIMPORT to load them automatically at their end.

[ChrisNZ]

Formats are stored in SAS catalogs (files with extension sas7bcat).

You can send this file and the recipient will be able to use the formats, provided the OS platform is the same.

[ben12]

Thanks Chris. 

I haven't used catalogs much, but - doesn't that mean that the client would still have to run a DATA step in order to attach the formats from the catalog file to the data which we sent them? And they would also have to identify where the catalog was stored before the formats in it could be used using the FMTSEARCH option? 

It's a good suggestion, but I just don't know if this would actually be any more efficient than just sending them a "*.sas" file with the formats in code. 

[ChrisNZ]

>I just don't know if this would actually be any more efficient than just sending them a "*.sas" file with the formats in code. 

Well, you need to them them at least a file with the formatting information.*

How do you define efficient?

If they put the catalog in their work directory, they have nothing else to do.

*Actually you don't.

The other option is to store the formatted values in the data set instead of the raw values. 

This way only one single file needs being sent.

[ben12]

The other option is to store the formatted values in the data set instead of the raw values. 

This way only one single file needs being sent.

Yes, that's what we currently do in certain cases. The problem with this is that it can massively blow out the file size. 

[Tom]

First thing to do is make sure you send a DICTIONARY along with your data.   Something that defines the data.  At a minimum it should show what datasets there are and for each dataset list the variables and their attributes.  One of the attributes is what display format you have attached to the variable.  If you have created custom formats then document those in the dictionary also.  Some people just send PROC CONTENTS printout, but I would prefer a tabular format that is easy to convert into a dataset.  Like a CSV file.

To send format definitions sending the source code as you mentioned is useful. You can also send a dataset that can be used with CNTLIN= option of PROC FORMAT to create the formats.

How complex are your formats? If they are just "data labels", that is a simple one to one decode of the meaning of the codes used in the variable then actually having the formats is not as important as having the documentation.

[Kurt_Bremser]

A .sas7bdat file (a dataset file) already contains the information which format is assigned to which variable.

So you only have to make sure that the formats are also present at the receiving end. Either send the proc format code that creates the formats, or a second dataset in CNTLIN format from which the formats can be created with a simple

proc format cntlin=cntlin;
run;

Include instructions on how the formats can be made permanent, if such is needed.

Documentation that comes with data is essential; see Maxim 16.