For the background to this series of summary posts see Altair SLC 2026 series: Introduction to posts.

Book links:

Book A: Advanced Altair SLC

Comparing Altair SLC with SAS Software

A-05 From CDISC ADaM data to a validated comparison

A clinical chapter written by people who have done the work.

It follows the data journey end to end: acquisition and cleaning, transformation and integration, statistical analysis, visualisation, report generation. It covers the CDISC tooling that works with Altair SLC, from the Clinical Standards Toolkit to the R Pharmaverse.

Then it gets practical. Download the sample ADaM data, configure Altair SLC to read it, and build a macro that standardises and compares ADaM data sets.

The chapter closes with an exercise and a worked answer, because reading about clinical programming is not the same as doing it.

Advanced Altair SLC, chapter 8.

#ClinicalResearch #CDISC #ADaM #AltairSLC #StatisticalProgramming

Book B: Altair SLC for Business Users

Working with Altair SLC day to day

B-05 Everything you actually have to read and write

The data never arrives in the format you wanted.

One chapter in Book B covers what a working programmer really reads and writes: delimited files with PROC IMPORT, PROC EXPORT and ODS CSV; Excel through the XLSX and EXCEL LIBNAME engines and through ODS EXCEL; Microsoft Access; dBase; MySQL and MariaDB; ODBC through both the ODBC and ODBCOLD engines; and OLEdb.

The database connections added in Altair SLC 2026 are listed separately from those already there in 2025, so you can tell at a glance whether an upgrade solves your problem.

Altair SLC for Business Users, chapter 7.

#AltairSLC #Excel #ODBC #SQL #DataEngineering

Book C: Altair SLC for Companies

The case, the cost and the migration

C-05 Find out before you commit, not after

Will your SAS programs run in Altair SLC? You can find out before you spend anything.

Analytics Workbench syntax checks whole folders of programs through Analyse then Program Compatibility, and reports missing procedures, system options, global statements and Data Step options to an Excel file. The free Personal Edition is enough to run that check.

Book C also lists the known false positives, so that DIMn() and LAGn() are not mistaken for blockers when they work perfectly well.

Altair SLC for Companies, section 10.2.1.

#AltairSLC #Migration #SAS #ITStrategy

We all know that SAS develops its software in separate teams, but it can be really annoying when it becomes apparent that several associated teams haven’t planned together how a SAS procedure will work.

I’m going to take as an example PROC IMPORT, which is part of Base SAS, but is also included in SAS/ACCESS. When you run the following program all the variables created begin with VAR, i.e. VAR1, VAR2, VAR3, VAR4, VAR5, etc., and this would also be true for DBMS=TAB and DLM:

PROC IMPORT FILE = "test.csv" DBMS = CSV REPLACE;
  GETNAMES = NO;
RUN;

However, using similar PROC IMPORT code for DBMS=EXCEL, in SAS/ACCESS for PC Files, will create variables beginning with F, i.e. F1, F2, F3, F4, F5, etc.:

PROC IMPORT FILE = "test.xls" DBMS = EXCEL REPLACE;
  GETNAMES = NO;
RUN;

More shocking though is using PROC IMPORT code for DBMS=XLS or XLSX in UNIX or Windows, in SAS/ACCESS for PC Files, as this will create variables with no prefix at all, i.e. A, B, C, D, E, etc.:

PROC IMPORT FILE = "test.xls" DBMS = XLS REPLACE;
  GETNAMES = NO;
RUN;

This inconsistency even extends to using GETNAMES = YES too when there are multiple columns with the same label.

If you want to import a CSV file, instead of an Excel file, or indeed import an Excel file in UNIX, then the subsequent processing step will have to be updated to use the new variable names (annoying!). Why can’t the procedure be consistent, or, at least, have a parameter, like PREFIX=, that allows users to choose the prefix?

Back in SAS 6 there were monumental problems caused by each SAS procedure having to manage their own output destinations, and each one doing it in a slightly different way, so ODS (Output Delivery System) was introduced in SAS 7 to make the output interface separate from the procedures. SAS now need to develop standards for parameters and defaults, just like they did for output!

To vote for this to be included in the next SASware Ballot just click here and vote up the idea!

Warning: you may need to use a desktop browser to vote up the idea! 🙁

Do you have any examples of similar inconsistencies in SAS?

Tag: EXCEL

Altair SLC 2026 series: Summary post #5