No Data Step Required: Creating Computed Columns on the Fly with table.fetch

Unlike PROC PRINT, which defaults to showing observation numbers, the table.fetch action often returns an _Index_ column that represents the row's position on a specific worker node, which can look random in a distributed environment. To get a cleaner output similar to a standard report, you can add the parameter index=FALSE to your statement (e.g., table.fetch / table='ventes' index=FALSE;) to hide this technical column.

To use it like a pro, remember these three best practices:

Be Resource Efficient: Always use the to= parameter to limit your results. Fetching millions of rows to your client session can cause significant latency or memory issues; stick to the first 20–100 rows for quick verification.

Leverage CAS-Side Processing: Use the where and sortBy parameters directly within the action. This ensures filtering and sorting happen in-memory within the CAS server before any data is transferred to your interface.

Enhance Readability: Take advantage of computedVars and format=true. By applying formats directly in the fetch action, you can transform raw data into business-ready insights (e.g., converting scores to "Pass/Fail" statuses) instantly without creating a new physical table.