BookmarkSubscribeRSS Feed
There is a bug in SAS that aggressively limits the length of variable names and cripples SAS's ability to interface with any well maintained literally name database.
54 Comments
Kurt_Bremser
Super User

@Angel_Boy Don't expect this to be implemented before a major release, as it necessitates a change in the dataset file structure (among other things). This is at least as big as the changes from the .ssd01 (SAS 6) format to .sas7bdat (7 onward).

So I would not expect it for any minor release within version 9, rather for version 10.

ChrisNZ
Tourmaline | Level 20

This entry supposedly supersedes https://communities.sas.com/t5/SASware-Ballot-Ideas/Metadata-More-space-please/idc-p/631403

which 

- is broader,

- has gathered more votes,

- was made before.

Tom
Super User
Super User

As I said four years ago on the other thread no matter what length is chosen there will always be data sources that use longer names.  So support for handling those needs to be built into the SAS/Access engines.

 

You would think that SAS/Access could take care of much of this for you.

For example for databases that do not have the LABEL concept it could generate a unique 32 character variable name (similar to PROC IMPORT) and store the actual variable (or dataset name) in the label (or memlabel) field.  You might even have an option to tell SAS/Access to use the LABEL of the variable as then name to use in the remote database.

 

It would also be nice if there was a method for user to specify the mapping similar to the DBTYPE dataset option.

ChrisNZ
Tourmaline | Level 20

> bug

You are confusing design and defect. Maybe you've used Microsoft products too much? 😉

This design choice was made when SAS V7 came out. The design choice was to increase the allowable name length from 8 to 32 characters. 

 

> 25% of the length of the column name width of most DB tools

Most? As in not Oracle. Not DB2. Just not the main players then...

 

Regardless, I agree that the option should be available. Whether we like it or not, having the choice would make some jobs easier.

Like UTF-8 encoding, this is the way the market seems to be moving, and all new players allow long names.

Rejecting the idea because it can be abused is not a good enough reason imho.

 

 

 

SASKiwi
PROC Star

Worth pointing out that with SAS 9 switching to limited support after 2025, this limitation is only likely to be addressed in Viya 4 (aka Viya 2020.n.n) which is on a much accelerated development cycle.

Quentin
Super User

Has there been an official statement by SAS that there will not be a SAS 9.5 or SAS 10?

SASKiwi
PROC Star

Here is the link to the official SAS Support Policy: https://support.sas.com/en/technical-support/services-policies.html

 

You can read between the lines that SAS 9.4 is the last release of SAS 9 technology and that SAS users will be expected to migrate to Viya over the next few years. I've heard this message from SAS contacts.

Quentin
Super User
Thanks. Agree with your conclusion. Since just about everyone has read behind the lines as you suggest, I wish SAS would make an official statement to that effect. I don’t see a reason for NOT making a clear statement that there will never be a 9.5 (or 10). Seems that at some point sooner or later, everyone running 9.x (PC or server) is going to be forced to the decision of Viya or nothing. We shouldn’t have to read tea leaves to guess when that will happen.
SASKiwi
PROC Star

@Quentin - Perhaps this news item state's SAS's plans more clearly: SAS analytics platform adds native support for AWS, GCP

Quentin
Super User
Thanks. Particularly the last bit:

“SAS' roadmap includes consolidating its various tools so customers can more easily migrate from SAS 9.4 to Viya and offering more industry-specific solutions.”